Software Fault Tolerance and Self-Healing System and Method

Abstract

This invention provides a software fault-tolerant self-healing system and method. The software fault-tolerant self-healing system includes a file server system, a storage system, and at least two onboard standalone systems. The file server system includes at least two network interface modules and a memory, with each network interface module establishing a communication connection with one of the two onboard standalone systems. The storage system includes a radiation-resistant cache memory and at least two communication interfaces, each of which establishes a communication connection with one of the two onboard standalone systems. This invention verifies and self-heals configuration data during software reload recovery and software system runtime, thereby improving system reliability.

Description

Technical Field

[0001] This invention belongs to the field of satellite technology, and in particular relates to a software fault-tolerant self-healing system and method. Background Technology

[0002] In space irradiation environments, hardening designs are typically implemented to enhance the fault tolerance of onboard software. This includes embedding critical programs and parameters in PROMs; presetting, checking, and resetting module input / output values; and partitioning storage areas to store important data using a two-out-of-three voting method. For more complex software systems, such as network operating systems, the services they handle are complex, and the main program parameter tables are intricate and constantly changing. Similarly, in onboard routing component systems, routing table entries are constantly changing due to satellite operations. Therefore, the traditional methods of embedding parameters and presetting module input / output values ​​are difficult to apply directly within the software system. Currently, a common approach is to partition storage devices such as Flash or SSDs, storing important data in triplicate across different partitions, and using a two-out-of-three voting method when data is needed. This method can ensure the correctness of data entries within a single software system to some extent, but when system-level anomalies or hardware failures occur requiring single-machine backup and failover, the critical data of the software system cannot be restored synchronously and in a timely manner.

[0003] Compared to the terrestrial environment, space irradiation has a significant impact on onboard software systems in the field of satellite constellation communications. Single-event effects, especially single-event upsets, in the space irradiation environment can lead to data changes in storage units, processor instruction errors, and software system logic chaos. From a system perspective, single-event latch-up and single-event burnout are hardware issues that cannot be self-healed in a single event. They are often designed to be addressed through current limiting protection and single-machine cold standby switching during overcurrent. After a single-machine switchover occurs, the software system must be reloaded and recovered. Summary of the Invention

[0004] In view of the problems existing in the prior art, the present invention provides a software fault-tolerant self-healing system and method, which at least partially solves the problem of data errors after the reload of the onboard software system on the spaceborne system, resulting in low reliability of software version, services and software system operation.

[0005] In a first aspect, embodiments of this disclosure provide a software fault-tolerant self-healing system, including a file server system, a storage system, and at least two onboard stand-alone systems. The file server system includes at least two network interface modules and a memory, and the two network interface modules establish communication connections with the two onboard stand-alone systems respectively. The storage system includes a radiation-resistant cache memory and at least two communication interfaces, and the two communication interfaces establish communication connections with the two onboard stand-alone systems respectively.

[0006] The file server system runs a file server, while the spaceborne standalone system runs a file client, a reload processing component, a fault-tolerant and self-healing component, a configuration management component, and a business component.

[0007] Optionally, the file server is used to store the version image file and full configuration data file of the spaceborne single-machine system, and also provides file transfer services;

[0008] The file client is the file interaction interface between the onboard standalone system and the file server system. It is used to receive instructions from the reload processing component, download the required version image file or full configuration data file from the file server, and complete the integrity verification.

[0009] The reload processing component is a software reload process control and processing component for the spaceborne single-machine system. It is used to select the software reload version when the spaceborne single-machine system starts up, trigger the version download and full configuration data file download, and control the version and configuration update process.

[0010] The fault-tolerant self-healing component is a processing component for verifying and self-healing configuration data errors in the runtime state of the spaceborne single-machine system. It is used to detect the runtime configuration of the service components during the runtime of the spaceborne single-machine system, perform configuration comparison and verification, and configuration error correction and self-healing.

[0011] The configuration management component is a processing component for configuration update and configuration storage maintenance. It is used to receive configuration update instructions from the overload processing component and complete the configuration update of the business component, receive configuration export instructions from the fault-tolerant self-healing component and complete the configuration export of the business component, export configuration snapshots in real time for classified multi-copy storage when the configuration of the business component changes, and load the configuration of the business component according to the configuration file.

[0012] The aforementioned business components are the functional carriers of the spaceborne single-machine system.

[0013] Secondly, this disclosure also provides a software fault-tolerant self-healing method, applied to the software fault-tolerant self-healing system described in the first aspect. The self-healing method includes...

[0014] Reload recovery of onboard software systems and fault tolerance and self-healing of configuration data during software system runtime;

[0015] When a single onboard system malfunctions, it triggers a power-down of itself and a power-on of another single onboard system. After the other single onboard system is powered on, the software system starts running with the software version currently in the memory. After the version starts, the onboard software system reload recovery process is executed.

[0016] The reload recovery of the onboard software system includes system information acquisition and comparison, software system version update, and software system configuration version update.

[0017] This invention provides a software fault-tolerant self-healing system and method. The system configures at least two onboard standalone systems, each connected to a file server system and a storage system. When an onboard system is overloaded due to a fault or other reason, the system data is loaded and verified through the onboard standalone systems and the storage system to prevent data errors, thereby improving system reliability. Attached Figure Description

[0018] The above and other objects, features and advantages of this disclosure will become more apparent from the accompanying drawings, in which like reference numerals generally denote like parts.

[0019] Figure 1 A schematic diagram of the software fault-tolerant self-healing system provided in the embodiments of this disclosure;

[0020] Figure 2 A software component block diagram of a software fault-tolerant self-healing system provided in this embodiment of the disclosure;

[0021] Figure 3 A flowchart of the overload recovery process provided in this embodiment of the disclosure;

[0022] Figure 4 A flowchart illustrating the overload recovery information comparison process provided in this embodiment of the disclosure;

[0023] Figure 5 A flowchart illustrating the online version update process provided in this embodiment of the disclosure;

[0024] Figure 6 A flowchart illustrating runtime configuration data fault tolerance and self-healing provided in this embodiment of the disclosure;

[0025] Figure 7 A flowchart illustrating the full configuration version update process provided in this embodiment of the disclosure. Detailed Implementation

[0026] The embodiments of this disclosure will now be described in detail with reference to the accompanying drawings.

[0027] It should be understood that the following specific examples illustrate the implementation of this disclosure, and those skilled in the art can easily understand other advantages and effects of this disclosure from the content disclosed in this specification. Obviously, the described embodiments are only a part of the embodiments of this disclosure, and not all of them. This disclosure can also be implemented or applied through other different specific implementation methods, and the details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of this disclosure. It should be noted that, in the absence of conflict, the following embodiments and features in the embodiments can be combined with each other. Based on the embodiments in this disclosure, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this disclosure.

[0028] It should be noted that various aspects of embodiments within the scope of the appended claims are described below. It will be apparent that the aspects described herein can be embodied in a wide variety of forms, and any particular structure and / or function described herein is merely illustrative. Based on this disclosure, those skilled in the art will understand that one aspect described herein can be implemented independently of any other aspect, and two or more of these aspects can be combined in various ways. For example, any number of aspects set forth herein can be used to implement the device and / or practice the method. Additionally, this device and / or method can be implemented using structures and / or functionalities other than one or more of the aspects set forth herein.

[0029] It should also be noted that the illustrations provided in the following embodiments are only schematic representations of the basic concept of this disclosure. The illustrations only show the components related to this disclosure and are not drawn according to the number, shape and size of the components in actual implementation. In actual implementation, the form, quantity and proportion of each component can be arbitrarily changed, and the layout of the components may also be more complex.

[0030] Furthermore, specific details are provided in the following description to facilitate a thorough understanding of the examples. However, those skilled in the art will understand that the described aspects can be practiced without these specific details.

[0031] This embodiment discloses a spaceborne software fault-tolerant self-healing system, which consists of two parts: hardware and software.

[0032] Hardware is the physical execution carrier of onboard software fault-tolerant systems. For example... Figure 1 As shown, the hardware includes a file server system, a storage system, and at least two onboard stand-alone systems. This embodiment uses two onboard stand-alone systems as an example, but is not limited to two. The storage system is a radiation-resistant high-speed storage system.

[0033] The file server system is a large-capacity storage hub, containing at least two network interface modules and a large-capacity storage device. The two network interface modules respectively connect to two spaceborne stand-alone systems.

[0034] The high-speed storage system is a radiation-resistant high-speed cache storage hub, which includes at least one radiation-resistant high-speed cache memory and two high-speed communication interfaces, with the two high-speed communication interfaces respectively connecting to two spaceborne single-unit systems;

[0035] Each onboard single-unit system includes at least one processor, one memory, one service processing chip, one network interface module, and one high-speed communication interface. Two onboard single-unit systems operate in a cold backup configuration and can be distinguished by different serial numbers, A / B configurations, or primary / secondary configurations.

[0036] The file server system in this embodiment can be a standalone hardware system, or it can be integrated into a single unit with other spaceborne units besides the spaceborne unit system to be protected. For example, if software system fault tolerance and self-healing protection are required for the spaceborne routing system, the file server system can be integrated into the spaceborne integrated electronic system.

[0037] As a standalone hardware system, the file server system can simultaneously provide file services to multiple onboard business components. For example, a single file server system can provide file services to the onboard autonomous management system, the onboard baseband system, and the onboard routing system.

[0038] like Figure 2 As shown, the software includes: a file server running on the file server system, a file client running on the satellite-based standalone system, a heavy-load processing component running on the satellite-based standalone system, a fault-tolerant and self-healing component running on the satellite-based standalone system, a configuration management component running on the satellite-based standalone system, and a business component running on the satellite-based standalone system.

[0039] The file server runs on the file server system and is used to store version image files and full configuration data files of the onboard single-machine system, while also providing highly reliable file transfer services.

[0040] The file client runs on the onboard standalone system and serves as the file interaction interface between the onboard standalone system and the file server system. It is used to receive instructions from the reload processing component, download the required version image file or full configuration data file from the file server, and complete the integrity verification.

[0041] The reload processing component runs on the spaceborne standalone system and is a software reload process control and processing component for the spaceborne standalone system. It is used to select the software reload version when the spaceborne standalone system starts up, trigger the version download and full configuration data file download, and control the version and configuration update process.

[0042] The fault-tolerant self-healing component runs on the spaceborne single-machine system. It is a processing component for verifying the runtime service configuration data and self-healing configuration data errors in the runtime state of the spaceborne single-machine system. It is used to detect the runtime configuration of the service components during the runtime of the spaceborne single-machine system, perform configuration comparison and verification, and perform configuration error correction and self-healing.

[0043] The configuration management component runs on the onboard single-machine system and is the processing component for configuration updates and configuration storage maintenance. It is used to receive configuration update instructions from the overload processing component and complete the configuration update of the business component, receive configuration export instructions from the fault-tolerant self-healing component and complete the configuration export of the business component, and export configuration snapshots in real time for classified multi-copy storage when the configuration of the business component changes.

[0044] The business components run on the onboard standalone system and are the functional carriers of the onboard standalone system, including data acquisition, interface management, routing management, etc.

[0045] The software fault-tolerant self-healing method disclosed in this implementation includes: reload recovery of the onboard software system and fault tolerance and fault self-healing of configuration data in the runtime state of the software system.

[0046] like Figure 3 As shown, this embodiment of the invention provides a method for reloading and recovering a spaceborne software system. When a spaceborne standalone system experiences a software or hardware malfunction, it triggers its own power-down and the power-on of another spaceborne standalone system. After the spaceborne standalone system powers on, the software system starts running with the software version currently stored in memory. After the version startup is complete, the software system reload recovery process is executed. Specifically, it includes the following steps:

[0047] Step 1: When the software system starts, the reload processing component reads the currently running single-machine information and the current full configuration version from the memory, and reads the currently running software version from the current software system as the first information set.

[0048] Step two: The overload processing component reads the currently running single-machine information, the software version to be effective, and the full configuration version to be effective from the high-speed storage system, as the second set of information.

[0049] Step 3: The reload processing component reads the last running single-machine information, the last software version, and the last full configuration version from the high-speed storage system as the third information set.

[0050] Step four, the reload processing component follows... Figure 4 The process involves comparing the first and second sets of information, following the order of comparing individual machine information first, then software version, and finally the full configuration version. After the comparison is complete, the next processing step is determined: no processing, configuration version update, or both software and configuration version update. If the next processing step is no processing, the reload process ends.

[0051] Step five: The reload processing component updates the software version. Based on the applicable software version from the second information set, it sends a software version retrieval command to the file client, obtains the image file of the applicable software version, writes it to the onboard standalone system, and then restarts the current software system. After restarting, the reload recovery process will re-enter.

[0052] Step 6: The reload processing component updates the software system configuration version. Based on the full configuration version that should take effect in the second information set, it sends a full configuration retrieval command to the file client to obtain the configuration file of the full configuration version that should take effect. It then writes the configuration file and configuration file version into the onboard standalone system and sends a configuration file update loading command to the configuration management component.

[0053] The onboard software system reload recovery process includes system information acquisition and comparison, software system version update, and software system configuration version update.

[0054] The steps for obtaining and comparing system information are as follows:

[0055] Obtain the first information set, the second information set, and the third information set. The first information set consists of the current running unit information, the current software version, and the current full configuration version of the onboard unit system; the second information set consists of the current running unit information, the software version to be activated, and the full configuration version to be activated stored in the high-speed storage system; the third information set consists of the last running unit information, the last software version, and the last full configuration version stored in the high-speed storage system.

[0056] Based on the acquired first and second information sets, a hierarchical comparison is performed. The first level compares the currently running single-machine information in the first information set with the currently running single-machine information in the second information set. If they do not match, it indicates a switchover event has occurred on the satellite-borne single-machine system, and the number of single-machine switchovers needs to be recorded in the high-speed storage system. If they match, it indicates a restart has occurred on the satellite-borne single-machine system, and the number of single-machine restarts needs to be recorded in the high-speed storage system. Then, the currently running single-machine information stored in the high-speed storage system is copied to the previously running single-machine information, and the currently running single-machine information of the satellite-borne single-machine system is copied to the currently running single-machine information in the high-speed storage system.

[0057] The current operating unit information of the spaceborne unit system is read from the memory by the overload processing component when the software system starts. This information may include, but is not limited to, the unit production number or the unit A / B role. The two spaceborne unit systems can be distinguished by this information.

[0058] A second-level comparison is performed, comparing the current software version of the first information set with the required effective software version of the second information set. If they do not match, the onboard software system version update and software system configuration update process are triggered. If they match, a third-level comparison is performed, comparing the current full configuration version of the first information set with the required full configuration version of the second information set. If the third-level comparison matches, the configuration loading process is directly initiated, sending a configuration loading command to the configuration management component, which then completes the configuration loading of the business components. If they do not match, only the software system configuration version update process is initiated.

[0059] like Figure 5 As shown, the software system version update process includes:

[0060] Step 1: After receiving the online update command sent from the ground, the software system reload processing component sends a software version retrieval command to the file client.

[0061] Step two: The file client obtains the software image file from the file server.

[0062] Step three: The file client verifies the software image file. If verification is successful, the software version and software image file are written to the onboard standalone system storage. If verification fails, return to step two. The online version update process ends when three failures occur.

[0063] Step 4: The reload processing component copies the software version that should be effective for the high-speed storage system to the previous software version, writes the updated software image file version number to the software version that should be effective for the high-speed storage system, and increments the software version update count by one.

[0064] The software system version update process is as follows: Based on the software version to be effective from the second information set, a software version retrieval command is sent to the file client to obtain the image file of the software version to be effective, and this image file is written to the onboard standalone system. Then, the current software system is restarted. After restarting, the software system reload recovery process is repeated, except for the software system configuration version update process.

[0065] The software system reload processing component supports online version updates for the software system. After receiving the online update command sent from the ground, the reload processing component sends a software version retrieval command to the file client. The file client retrieves the software image file from the file server for online update and writes it to the onboard standalone system. Then, it copies the software version that should be effective in the high-speed storage system to the previous software version, writes the updated software image file version number to the software version that should be effective in the high-speed storage system, and increments the software version update count by one.

[0066] The software image file is uploaded from the ground and stored on the file server system. The software image file contains the image file and a verification code. The file server saves a copy of the image file and verification code. When it receives a request from the file client to retrieve the software image file, it performs a verification code calculation and check. If the check fails, it retrieves the image file from the copy. If this also fails, it returns an error message to the file client, indicating that the file client failed to retrieve the configuration file. If the file client fails to retrieve the file from the file server, it returns an online update failure message, the reload processing component exits the software version update process, and restarts the software version update process with the previous software version.

[0067] After the file client obtains the software image file from the file server, it calculates the verification code of the image file and checks whether it matches the verification code of the software image obtained from the file server. If the check fails, the obtained software image file is deleted, and the client obtains the software image file from the file server again and repeats the verification code check. If the copy check fails for a first set number of times, an error message is returned indicating that the file client failed to obtain the software image file from the file server. The first set number of times can be set according to requirements, such as 3 times, etc.

[0068] The software system configuration version update process is as follows: Based on the full configuration version to be effective from the second information set, a full configuration retrieval command is sent to the file client to obtain the configuration file for the full configuration version to be effective, and write it to the onboard standalone system. Then, a configuration file update execution command is sent to the configuration management component. If the file client fails to retrieve the full configuration file from the file server, the configuration version update process is performed using the previous configuration version.

[0069] The file client receives a full configuration retrieval command and requests the full configuration file of the version to be applied from the file server. The file server saves a copy of the full configuration file and its verification code. When it receives the full configuration file retrieval message from the file client, it performs a full configuration file verification code calculation and check. If the check fails, it retrieves the full configuration file from the copy. If it fails again, it returns an error message to the file client, indicating that the file client failed to retrieve the full configuration file.

[0070] After the file client obtains the full configuration file from the file server, it calculates the full configuration file checksum and checks if it matches the checksum obtained from the file server. If the check fails, the obtained full configuration file is deleted, and the client obtains it again from the file server, repeating the checksum verification. If the check fails a second set number of times, an error message is returned indicating that the file client failed to obtain the full configuration file from the file server. The second set number of times can be set according to requirements, such as 3 times, etc.

[0071] like Figure 6 As shown, the fault tolerance and self-healing methods for configuration data in the system's runtime state include:

[0072] Step 1: The fault-tolerant and self-healing component periodically sends configuration collection commands to the configuration management component.

[0073] Step two: The configuration management component collects configurations, exports business component configurations to a full runtime configuration data file, and then exports key business configurations to a key runtime configuration data file.

[0074] Step 3: The fault-tolerant self-healing component compares the runtime critical configuration data file with the critical configuration data file of the high-speed storage system for consistency. If they match, this round of the process ends. If they do not match, proceed to step 4.

[0075] Step 4: The fault-tolerant self-healing component sends a configuration data recovery command to the configuration management component based on the critical configuration data file.

[0076] Step 5: The configuration management component executes the critical configuration data files stored in the high-speed storage system to refresh the critical configurations of the business components.

[0077] Configuration data fault tolerance and self-healing in the runtime of a software system are used to detect the configuration data of business components within the software system during runtime and perform configuration data fault tolerance and self-healing. Configuration data fault tolerance and self-healing in the runtime of a software system includes the collection of all and critical configuration data of the software system, the collection of configuration data in the business runtime, configuration data verification, and configuration data recovery.

[0078] The collection of full and critical configuration data for the software system is completed by the configuration management component. The configuration management component divides the full configuration of the software system into critical configurations and general configurations. Critical configurations are the set of configurations that affect the core startup process of the software system and have a decisive impact on the establishment of basic communication links, including but not limited to management address configuration, underlying interface configuration, and user login authentication configuration. General configurations refer to the set of configurations used to extend system functions, excluding critical configurations, including but not limited to business strategy configurations and operation and maintenance configurations. After processing changes to the software system configuration, the configuration management component collects the full and critical configurations of the software system, assigns a version number to the full configuration, and records it as the version of the full configuration that should take effect. The configuration management component sends a command to the file client to send the full configuration to the file server. The configuration management component stores the critical configuration files and the version of the full configuration that should take effect in a high-speed storage system. When storing the version of the full configuration that should take effect, the configuration management component first copies the original version of the full configuration that should take effect to the previous version, increments the configuration version update count by one, and then stores the version of the full configuration that should take effect.

[0079] The collection of runtime configuration data is handled by the configuration management component. The fault-tolerant and self-healing component periodically sends configuration collection commands to the configuration management component, which then collects the configurations of the business components. The configuration management component exports all business component configurations to a runtime full configuration data file, identifies and categorizes key configurations, and exports these key configurations to a runtime key configuration data file.

[0080] Configuration data verification and recovery are handled by the fault-tolerant self-healing component. The fault-tolerant self-healing component periodically sends configuration collection commands to the configuration management component. After the configuration management component completes configuration collection, the fault-tolerant self-healing component compares the critical configuration data file stored in the high-speed storage system with the exported runtime critical configuration data file. If they match, the configuration data verification process is complete. If they do not match, it indicates an error or failure in the runtime critical configuration. In this case, the critical configuration data file is used as a parameter to send a configuration data recovery command to the configuration management component. Upon receiving the configuration data recovery command, the configuration management component executes the critical configuration data file to refresh the critical configuration of the business components.

[0081] like Figure 7 As shown, the full configuration version of the software system includes:

[0082] Step 1: After processing the software system configuration changes, the configuration management component collects the full configuration and critical configurations of the software system, and records the version number of the full configuration as the version of the full configuration that should take effect.

[0083] Step two: The configuration management component sends a command to the file client to send the full configuration to the file server.

[0084] Step 3: The configuration management component copies the full configuration version that should take effect, stored in the high-speed storage system, to the previous full configuration version and increments the configuration version update count by one.

[0085] Step four: The configuration management component stores the critical configuration files in a high-speed storage system.

[0086] The two onboard single-machine systems operate on a cold backup basis. If a hot backup method were used, the modified onboard software fault tolerance and self-healing method would still be applicable. After the two onboard single-machine systems power on and determine their primary and backup roles, the primary onboard single-machine system executes a software reload recovery process. The backup onboard single-machine system, after the primary system's software reload recovery process is complete, acquires information from the primary system's first information set (excluding single-machine information) and compares it with this information. If discrepancies exist, the backup system's software version and configuration are reloaded and updated using the primary system's first information set software version and configuration version to maintain consistency with the primary system's software version and configuration. The configuration data fault tolerance and self-healing method for the software system's runtime state can also run simultaneously on both the primary and backup onboard single-machine systems. This method is used by both systems to detect the configuration data of business components within the software system during runtime and perform configuration data fault tolerance and self-healing.

[0087] The software fault-tolerant self-healing system and method disclosed in this embodiment also have the following beneficial effects:

[0088] 1. The dual-machine cold backup architecture of the spaceborne single machine, combined with the design of a radiation-resistant high-speed storage system directly connected to the dual machines, and the heavy-load recovery method that works in concert with the heavy-load processing components and the high-speed storage system, enables seamless recovery of software versions and full configurations during fault switching.

[0089] 2. By comparing the runtime configuration with the baseline configuration in the high-speed storage system through periodic verification, configuration data errors can be automatically detected and self-healed.

[0090] 3. Automated configuration, operation fault detection, and self-healing mechanisms reduce reliance on ground intervention and improve the reliability of long-term on-orbit operation of spaceborne single-unit systems.

[0091] The basic principles of this disclosure have been described above with reference to specific embodiments. However, it should be noted that the advantages, benefits, and effects mentioned in this disclosure are merely examples and not limitations, and should not be considered as essential features of each embodiment of this disclosure. Furthermore, the specific details disclosed above are for illustrative and facilitative purposes only, and are not limitations. These details do not limit the scope of this disclosure to the necessity of employing the aforementioned specific details for implementation.

[0092] In this disclosure, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. The block diagrams of devices, apparatuses, devices, and systems involved in this disclosure are merely illustrative examples and are not intended to require or imply that they must be connected, arranged, or configured in the manner shown in the block diagrams. As those skilled in the art will recognize, these devices, apparatuses, devices, and systems can be connected, arranged, and configured in any manner. Words such as "comprising," "including," "having," etc., are open-ended terms meaning "including but not limited to," and are used interchangeably with them. The terms "or" and "and" as used herein refer to the terms "and / or," and are used interchangeably with them unless the context clearly indicates otherwise. The term "such as" as used herein refers to the phrase "such as but not limited to," and is used interchangeably with it.

[0093] Additionally, as used herein, the "or" used in a list of items beginning with "at least one" indicates a separate list, such that a list of, for example, "at least one of A, B, or C" means A or B or C, or AB or AC or BC, or ABC (i.e., A and B and C). Furthermore, the word "exemplary" does not imply that the described example is preferred or better than other examples.

[0094] It should also be noted that in the systems and methods of this disclosure, the components or steps can be decomposed and / or recombined. These decompositions and / or recombinations should be considered as equivalent solutions to this disclosure.

[0095] Various changes, substitutions, and modifications can be made to the technology described herein without departing from the teachings defined by the appended claims. Furthermore, the scope of the claims of this disclosure is not limited to the specific aspects of the processes, machines, manufactures, events, means, methods, and actions described above. Currently existing or later-developed processes, machines, manufactures, events, means, methods, or actions that perform substantially the same function or achieve substantially the same result as the corresponding aspects described herein can be utilized. Therefore, the appended claims include such processes, machines, manufactures, events, means, methods, or actions within their scope.

[0096] The above description of the disclosed aspects is provided to enable any person skilled in the art to make or use this disclosure. Various modifications to these aspects will be readily apparent to those skilled in the art, and the general principles defined herein may be applied to other aspects without departing from the scope of this disclosure. Therefore, this disclosure is not intended to be limited to the aspects shown herein, but rather to be carried out within the widest scope consistent with the principles and novel features disclosed herein.

[0097] The above description has been given for purposes of illustration and description. Furthermore, this description is not intended to limit the embodiments of this disclosure to the forms disclosed herein. Although numerous exemplary aspects and embodiments have been discussed above, those skilled in the art will recognize certain variations, modifications, alterations, additions, and sub-combinations therein.

Claims

1. A software fault-tolerant self-healing system, characterized by, The file server system comprises at least two network interface modules and a memory, the two network interface modules are respectively connected with the two satellite computer systems, and the memory system comprises an anti-radiation cache memory and at least two communication interfaces, the two communication interfaces are respectively connected with the two satellite computer systems. The file server system runs a file server, the satellite computer system runs a file client, a reload processing component, a fault-tolerant self-healing component, a configuration management component and a service component. The file server is used for storing version image files and full-configuration data files of the satellite computer system and simultaneously providing a file transmission service. The file client is a file interaction component of the satellite computer system and the file server system, used for receiving instructions of the reload processing component, downloading required version image files or full-configuration data files from the file server and completing integrity check. The reload processing component is a software reload process control processing component of the satellite computer system, used for selecting a software reload version when the satellite computer system starts, triggering version download and full-configuration data file download and controlling version and configuration update processes. The fault-tolerant self-healing component is a processing component for running-state service configuration data check and configuration data error self-healing of the satellite computer system, used for detecting running-state configurations of the service component when the satellite computer system runs, performing configuration comparison check and configuration error correction self-healing. The configuration management component is a processing component for configuration update and configuration storage maintenance, used for receiving configuration update instructions of the reload processing component and completing service component configuration update, receiving configuration export instructions of the fault-tolerant self-healing component and completing service component configuration export, exporting configuration snapshots in real time for classified multi-copy storage when service component configurations change and loading the service component according to configuration files. The service component is a functional carrier of the satellite computer system.

2. The software fault-tolerant self-healing method of claim 1, applied to the software fault-tolerant self-healing system of claim 1, wherein, The self-healing method comprises, software system reload recovery and software system running-state configuration fault tolerance and failure self-healing of the satellite software system; When the satellite computer system is abnormal due to self-running, the satellite computer system is powered off and another satellite computer system is powered on; after the other satellite computer system is powered on, the software system starts running with a software version in the current memory, and after the version starts, the software system reload recovery process is executed. The software system reload recovery comprises system information acquisition and comparison, satellite software system version update and software system configuration version update.

3. The software fault-tolerant self-healing method according to claim 2, wherein The system information acquisition and comparison comprises: acquiring a first information set, a second information set and a third information set, based on the acquired first information set and second information set, performing comparison in a hierarchical manner; the hierarchical comparison comprises first-level comparison, second-level comparison and third-level comparison.

4. The software fault-tolerant self-healing method according to claim 3, wherein The first information set includes current running single machine information, current software version and current full configuration version of the satellite-borne single machine system; The second information set includes current running single machine information, effective software version and effective full configuration version stored in the storage system; The third information set includes last running single machine information, last software version and last full configuration version stored in the storage system.

5. The software fault-tolerant self-healing method of claim 4, wherein the first level comparison further comprises comparing the current running single machine information of the first information set with the current running single machine information of the second information set; if the comparison result is inconsistent, recording the number of single machine switching in the storage system; if the comparison result is consistent, recording the number of single machine restart in the storage system, copying the current running single machine information stored in the storage system to the last running single machine information, and copying the current running single machine information of the satellite-borne single machine system to the current running single machine information of the storage system; The second level comparison comprises comparing the current software version of the first information set with the effective software version of the second information set; if the comparison result is inconsistent, triggering the satellite-borne software system version update and software system configuration update processes; if the comparison result is consistent, performing the third level comparison; The third level comparison comprises comparing the current full configuration version of the first information set with the effective full configuration version of the second information set; if the comparison result is consistent, starting the configuration loading process, sending a configuration loading instruction to the configuration management component, and completing the configuration loading of the business component by the configuration management component; if the comparison result is inconsistent, starting the software system configuration version update process. The satellite-borne software system version update comprises: sending a software version acquisition instruction to the file client according to the effective software version of the second information set, acquiring the image file of the effective software version, writing the image file into the satellite-borne single machine system, and then restarting the current software system; 6. The software fault-tolerant self-healing method of claim 4 or 5, wherein, the software image file is uploaded from the ground and stored in the file server system, and the software image file includes an image file and a check code; after receiving the online update instruction sent from the ground, the reload processing component sends a software version acquisition instruction to the file client, the file client acquires the software image file online from the file server, writes the software image file into the satellite-borne single machine system, then copies the effective software version of the storage system to the last software version, writes the version number of the updated software image file into the effective software version of the storage system, and increments the software version update number by one; the file server stores a copy of the image file and the check code, and when receiving the software image file acquisition message sent by the file client, the file server checks the check code of the image file; if the check fails, the file server acquires the image file from the copy; if the check of the copy fails again, the file server returns an error message to the file client, and the file client fails to acquire the configuration file; ​ ​ The file client calculates the check code of the software image file and checks whether the check code is consistent with the check code of the software image file obtained from the file server; if the check fails, the file client deletes the obtained software image file, re-obtains the software image file from the file server, and repeats the check code check; if the check fails for a first set number of times, the file client returns an error message indicating that the file client fails to obtain the software image file from the file server; If the file client fails to obtain the file from the file server, the file client returns an online update failure message, and the reloaded processing component exits the software version update process. The software version update process is performed again using the previous software version.

7. The software fault-tolerant self-healing method of claim 4, wherein, The software system configuration version update includes: According to the effective full-configuration version of the second information set, the file client sends a full-configuration obtaining instruction to the file server, obtains the configuration file of the effective full-configuration version, and writes the configuration file into the on-board single computer system, and then sends a configuration file update execution instruction to the configuration management component; if the file client fails to obtain the full-configuration file from the file server, the configuration version update process is performed using the previous configuration version; Upon receiving the full-configuration obtaining instruction, the file client obtains the full-configuration file of the effective full-configuration version from the file server. The file server stores a copy of the full-configuration file and the check code. Upon receiving the full-configuration file obtaining message sent by the file client, the file server checks the check code of the full-configuration file. If the check fails, the file server obtains the full-configuration file from the copy. If the check fails again, the file server returns an error message to the file client, and the file client fails to obtain the full-configuration file. Upon obtaining the full-configuration file from the file server, the file client calculates the check code of the full-configuration file and checks whether the check code is consistent with the check code of the full-configuration file obtained from the file server. If the check fails, the file client deletes the obtained full-configuration file, re-obtains the full-configuration file from the file server, and repeats the check code check. If the check fails for a second set number of times, the file client returns an error message indicating that the file client fails to obtain the full-configuration file from the file server.

8. The software fault-tolerant self-healing method of claim 2, wherein, The software system running state configuration data fault tolerance and fault self-recovery includes: Software system full-configuration and key configuration data collection, business running state configuration data collection, configuration data verification, and configuration data recovery. The software system full-configuration and key configuration data collection includes that the configuration management component divides the software system full-configuration into key configuration and general configuration, and sends an instruction to the file client to send the full-configuration to the file server. The configuration management component stores the key configuration file and the effective full-configuration version in the storage system. When the configuration management component stores the effective full-configuration version, the configuration management component first copies the original effective full-configuration version to the previous full-configuration version, increments the configuration version update number by one, and then stores the effective full-configuration version.

9. The software fault tolerance and self-recovery method of claim 8, wherein The service running state configuration data collection comprises that the fault-tolerant self-recovery component initiates a configuration collection instruction to the configuration management component at a timing, the configuration management component completes the configuration collection of the service component, the configuration management component exports all the collected service component configurations to a running state full configuration data file, and performs key configuration identification and classification, and the identified key configurations are exported to a running state key configuration data file; The configuration data verification and configuration data recovery comprise that the fault-tolerant self-recovery component initiates a configuration collection instruction to the configuration management component at a timing, after the configuration management component completes the configuration collection, the fault-tolerant self-recovery component compares the key configuration data file saved in the storage system and the running state key configuration data file exported this time, if the two are consistent, the configuration data verification process is completed, if there is inconsistency, the key configuration data file is taken as a parameter, a configuration data recovery instruction is sent to the configuration management component, the configuration management component receives the configuration data recovery instruction, performs key configuration data file configuration loading, and thus the key configurations of the service component are updated.

Images