Orbit period aware fault tolerance method and system for a spaceborne computer system

Abstract

The application provides an orbit period-aware fault-tolerant method and system for a satellite computer system. The satellite computer system comprises a main computing board. The orbit period-aware fault-tolerant method for the satellite computer system comprises: determining whether a satellite is in a safe orbit segment or a risk orbit segment based on the environmental radiation flux of the current orbit of the satellite obtained in real time; in response to determining that the satellite is in the safe orbit segment, performing incremental checkpoint data backup on the main computing board at a first frequency; and in response to determining that the satellite is in the risk orbit segment, performing the incremental checkpoint data backup on the main computing board at a second frequency higher than the first frequency. According to the orbit period-aware fault-tolerant method and system for the satellite computer system, the redundancy backup overhead of the satellite computer system can be greatly reduced, a transition from passive defense to predictive fault tolerance is achieved, and task continuity protection at a non-susceptible level is constructed.

Description

Technical Field

[0001] This application relates to spaceborne computing, and more particularly to fault-tolerant methods and systems for spaceborne computer systems. Background Technology

[0002] The statements in this section are merely to provide background information in relation to this application to aid in understanding it, and such background information does not necessarily constitute prior art.

[0003] Space-based computing (also known as space computing power or on-orbit computing) is a new computing paradigm that relies on spacecraft platforms such as satellites to deploy computing and storage resources in orbit. It breaks the traditional "on-board data acquisition, ground processing" separation model, becoming the core foundation for building an integrated space-air-ground computing network by completing real-time acquisition, intelligent analysis, and decision output of space data in orbit. As space-based computing gradually becomes an important part of the global information infrastructure, spaceborne computer systems are undergoing a gradual evolution from traditional control logic processing to high-performance on-orbit processing (e.g., real-time processing of on-board remote sensing images and large-scale artificial intelligence model inference). This high-performance processing system introduces a large number of high-performance computing devices with high parallel computing capabilities and flexible customizability, such as high-density field-programmable gate arrays (FPGAs), digital signal processors (DSPs), and neural processing units (NPUs)—multi-core heterogeneous processors. However, the widespread high-energy protons and cosmic rays in space continuously penetrate and strike spacecraft, easily triggering single-event upsets or single-event latch-ups in the internal logic units of the devices. Therefore, fault-tolerant strategies must be adopted to ensure the stable operation of onboard computer systems undertaking high-performance computing tasks.

[0004] Currently, besides employing triple modular redundancy and error detection and correction codes at the underlying hardware level, spaceborne computer systems generally adopt a "checkpoint and rollback recovery" mechanism at the architectural level. Traditional checkpointing mechanisms typically employ a static timed triggering strategy. This strategy involves the system relying on a built-in timer to forcibly pause the current computation task at fixed intervals, globally copying all task state data from the processor's register context, cache, and main memory, and writing it to radiation-resistant non-volatile memory. Once the hardware-level watchdog or error detection module detects a program malfunction, the system is reset, reads the state from the most recently saved global checkpoint, and resumes execution of the computation task.

[0005] While existing static checkpoints and rollback recovery mechanisms provide some fault tolerance, they suffer from drawbacks such as wasted computing power and delayed protection when facing high-computing space applications in complex space environments, making it difficult to effectively support the reliable execution of complex computing tasks. Summary of the Invention

[0006] Therefore, the purpose of this application is to provide an orbital period awareness fault-tolerant method, system, and computer program product for spaceborne computer systems, so as to provide a stable and efficient operating environment for spaceborne computer systems undertaking high computing power processing tasks.

[0007] According to a first aspect of this application, an orbital period-aware fault-tolerant method for a spaceborne computer system is provided, wherein the spaceborne computer system includes a main computing board, and the method includes:

[0008] The satellite is determined to be in a safe orbit or a risky orbit based on the real-time acquired environmental radiation flux of its current orbit.

[0009] In response to determining that the satellite is in the safe orbit segment, incremental checkpoint data backup is performed on the primary computing board at a first frequency;

[0010] In response to determining that the satellite is in the risky orbit segment, the incremental checkpoint data backup is performed on the primary computing board at a second frequency higher than the first frequency.

[0011] According to the method of this application, preferably, determining whether the satellite is in a safe orbit segment or a risky orbit segment based on the real-time acquired environmental radiation flux of the satellite's current orbit includes:

[0012] The system collects the three-dimensional coordinates of the satellite's current orbit in real time and obtains ephemeris data.

[0013] Based on the three-dimensional coordinates and the ephemeris data, calculate the environmental radiation flux;

[0014] The ambient radiation flux is queried in real time, and based on the ambient radiation flux and the single-particle flip section parameters of the main computing board, the expected hardware failure rate of the main computing board in the current time window and future time windows is calculated in real time.

[0015] The satellite is determined to be in the safe orbit segment or the risk orbit segment based on a comparison between the expected hardware failure rate and a preset safety threshold.

[0016] The method according to this application preferably further includes:

[0017] When it is determined that the satellite is in the risky orbit segment, the expected hardware failure rate is compared with a predetermined danger threshold;

[0018] When the expected hardware failure rate is less than the danger alarm threshold, a scheduling instruction is issued to cause the primary computing board to perform data backup in baseline operating mode.

[0019] According to the method of this application, preferably, the baseline operating mode includes:

[0020] Temporarily suspend or reduce the priority of non-real-time computing tasks on the main computing board;

[0021] Perform a full copy of the main computing board's memory state to generate a full baseline checkpoint dataset, and use this as a security baseline snapshot for rapid data recovery in subsequent deployments; and

[0022] The incremental checkpoint data backup is performed on the main computing board at a third frequency that is greater than the first frequency and less than the second frequency.

[0023] According to the method of this application, preferably, when the expected hardware failure rate is greater than or equal to the danger alarm threshold, the following operation is performed:

[0024] The incremental checkpoint data backup is performed on the main computing board at the second frequency;

[0025] Priority protection is applied to components related to core computing tasks in the onboard computer system.

[0026] Suspend, reduce the frequency of or migrate non-real-time computing tasks or low-priority computing tasks on the main computing board;

[0027] Increase the frequency of status detection and error checking of the primary computing board; and

[0028] Shorten the time window for health assessment of the main computing board.

[0029] The method according to this application preferably further includes:

[0030] A global health monitoring matrix is ​​constructed and updated periodically according to a set period. The global health monitoring matrix includes the health score of each computing board in all computing boards in the onboard computer system.

[0031] When the expected hardware failure rate is greater than or equal to the danger alarm threshold, compare the health score of the first primary computing board that is executing the core computing task with the lower limit safety threshold.

[0032] When the health score of the first primary computing board falls below the lower safety threshold, the task migration logic is automatically triggered. The task migration logic includes:

[0033] Disconnect the communication link of the first primary computing board;

[0034] Select the redundant standby computing board with the highest current health score and idle computing resources from the global health monitoring matrix as the takeover node;

[0035] Read the most recently generated full baseline checkpoint data set from the first primary computing board to reconstruct the latest complete task context in the redundant standby computing board; and

[0036] The core computing task continues to be executed using the redundant backup computing boards.

[0037] According to the method of this application, preferably, the incremental checkpoint data backup includes:

[0038] Perform an incremental backup operation as follows:

[0039] At the start of the incremental backup operation, all status bits in the dirty page status record table configured inside the primary computing board are reset to zero, wherein each status bit corresponds to a physical memory page in the physical memory space of the primary computing board; and

[0040] During the incremental backup operation, when a write operation instruction is initiated on a specific physical memory page, the status bit corresponding to that specific physical memory page is set to "1"; and

[0041] After the incremental backup operation is completed, perform the incremental checkpoint save operation as follows:

[0042] The dirty page status record table is traversed, and only physical memory page data with a status bit of "1" are extracted as incremental context into the cache of the main computing board.

[0043] The method according to this application preferably further includes:

[0044] A dynamic orbital risk index is calculated based on the weighting of the mission sensitivity coefficient and the correction factor for on-orbit historical fault statistics; and

[0045] The dynamic orbit risk index is compared with preset risk level thresholds; and

[0046] Based on the comparison results, the backup mode adopted by the primary computing board for performing data backup is determined.

[0047] According to a second aspect of this application, an onboard computer system is provided, which includes a controller configured to perform a method according to an embodiment of this application.

[0048] According to a third aspect of this application, a computer program product is provided, having a computer program or instructions stored thereon that, when executed, implements the method according to an embodiment of this application.

[0049] The orbital period awareness fault-tolerant method and system for spaceborne computer systems according to this application can greatly reduce the redundancy backup overhead of spaceborne computer systems, realize the leap from passive defense to predictive fault tolerance, and build a seamless level of mission continuity assurance. Attached Figure Description

[0050] The embodiments of this application will be further described below with reference to the accompanying drawings, wherein:

[0051] Figure 1 A schematic flowchart of an orbital period-aware fault-tolerant method for a spaceborne computer system according to an embodiment of this application is shown.

[0052] Figure 2 A flowchart illustrating an orbital period-aware fault-tolerant method for a spaceborne computer system according to another embodiment of this application is shown.

[0053] Figure 3 A schematic diagram of a spaceborne computer system according to an embodiment of this application is shown;

[0054] Figure 4 A schematic diagram illustrating the expected hardware failure rate according to one embodiment of this application is shown;

[0055] Figure 5 A schematic diagram illustrating the method for activating the dirty page bitmap function in the physical memory space of a primary computing board according to an embodiment of this application is shown. Detailed Implementation

[0056] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description, in conjunction with the accompanying drawings and specific embodiments, further illustrates this application. It should be understood that the described embodiments are only a part of the embodiments of this application, and not all of them. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0057] Furthermore, the described features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. Numerous specific details are provided in the following description to give a thorough understanding of embodiments of this application. However, those skilled in the art will recognize that the technical solutions of this application can be practiced without one or more of the specific details, or other methods, components, apparatuses, steps, etc., can be employed. In other instances, well-known methods, apparatuses, implementations, or operations are not shown or described in detail to avoid obscuring various aspects of this application.

[0058] The block diagrams shown in the attached figures are merely functional entities and do not necessarily correspond to physically independent entities. These functional entities can be implemented in software, within one or more hardware modules or integrated circuits, or in different network and / or processor devices and / or microcontroller devices.

[0059] The flowcharts shown in the accompanying drawings are merely illustrative and do not necessarily include all content and operations / steps, nor do they necessarily have to be performed in the described order. For example, some operations / steps can be broken down, while others can be combined or partially combined; therefore, the actual execution order may change depending on the specific circumstances.

[0060] Through practical experience, the inventors discovered that existing static checkpointing and rollback recovery technologies have the following pressing problems when facing high-performance spaceborne computing applications in complex space environments:

[0061] (1) The triggering strategy of the checkpoint mechanism lacks the ability to dynamically perceive the space radiation environment.

[0062] Existing fault-tolerance strategies heavily rely on fixed-period timer triggering (e.g., performing backups at a fixed frequency of every 10 minutes). This mechanism fails to match the physical characteristics of the satellite's actual orbit. In reality, the radiation environment during satellite operation exhibits significant periodicity and regionality. For example, when a satellite passes through the South Atlantic Anomaly (SAA) or auroral zones, the high-energy particle flux increases dramatically. A fixed-frequency backup strategy would result in the system performing numerous unnecessary redundant backups during low-radiation "safe orbital segments," leading to a severe waste of onboard computing resources. Conversely, during "high-risk orbital segments," the fixed-frequency backup strategy is often insufficient to handle sudden increases in single-event upset probabilities. In the event of a failure, all high-intensity computational progress since the last checkpoint would be completely lost.

[0063] (2) Saving all state data for high-computing-power tasks will result in unacceptable performance overhead.

[0064] With technological advancements, spaceborne computer systems are evolving towards higher computing power, such as deploying large-scale onboard model inference and real-time processing of high-resolution optical images. The context states and memory usage of computing tasks are increasing exponentially. However, current technologies mostly employ a "full checkpoint" approach, requiring massive amounts of memory data to be written to radiation-resistant non-volatile memory via the bus each time a backup is triggered. This not only causes severe I / O congestion and significantly increases "fault-tolerant downtime," but also accelerates the physical wear and tear of onboard solid-state storage media due to frequent large-scale data erasures and writes, thus shortening the system's lifespan.

[0065] (3) The fault recovery mechanism is lagging behind, and there is a lack of cross-node task migration and health-based scheduling strategies.

[0066] Existing onboard fault-tolerance technologies typically employ a "post-incident recovery" mechanism. This means that only after the error detection module reports a serious error or even a system crash is a forced reset and rollback attempt performed on the currently damaged computing node. However, high-energy particle radiation can sometimes lead to a sustained decline in device performance or physical anomalies such as single-event latch-up that are difficult to eliminate immediately. These physical anomalies are often used to determine hardware health. Existing technologies lack a "predictive" scheduling mechanism based on hardware health assessment, failing to proactively mitigate risks before a complete system failure. Furthermore, existing technologies lack strategies for smoothly migrating and rapidly taking over tasks across multiple heterogeneous computing boards using lightweight state data, significantly compromising the overall availability and task continuity of onboard computing clusters.

[0067] In the early explorations of fault tolerance mechanisms for spaceborne computer systems, preliminary technical solutions attempted to adopt a traditional architecture combining high-frequency global checkpoints with local redundancy. However, this approach revealed a fatal performance bottleneck during stress testing in actual simulations. For high-computing tasks such as complex onboard data processing, the scale of context state and memory data is extremely large, and the frequent saving of full state data easily leads to severe congestion on the onboard storage bus. This storage wall effect caused by massive data migration results in a precipitous drop in the system's effective computational throughput, and the physical contradiction between computing power and fault tolerance overhead has become a technical barrier that urgently needs to be overcome.

[0068] To overcome the bottlenecks inherent in pure computer architecture, the inventors attempted to introduce dynamic sensing capabilities of the satellite's space radiation environment. By jointly extracting and studying a large amount of historical telemetry data on single-event faults in orbit and satellite ephemeris characteristics, the inventors discovered that software and hardware faults caused by space radiation are not uniformly distributed over time, but rather exhibit a strong spatiotemporal correlation with the period during which the satellite traverses a specific high-radiation orbit. Based on this physical law, this application introduces a novel technical approach: using the spacecraft's space orbital characteristics as a pre-control variable for scheduling the underlying hardware state machine. This application constructs an adaptive triggering mechanism based on dynamic risk identification by introducing an orbital radiation model (space radiation environment model) and combining it with fault statistical characteristics, thereby accurately delineating safe and risky orbital segments. This fundamentally solves the scheduling problem of fault-tolerant triggering timing.

[0069] After establishing the dynamic environment awareness logic, this application further optimizes the memory controller architecture to address the underlying implementation challenges of low-overhead backup. By introducing a dirty page tracking mechanism at the hardware level, this application can silently save incremental checkpoints within a relatively long safe orbit segment with minimal communication bandwidth consumption. Furthermore, considering that computing devices are highly susceptible to irreversible failures or even partial and complete system crashes in high-risk radiation areas, traditional single-board in-situ recovery strategies pose a significant single-point-of-failure risk. Therefore, the architecture of this application ultimately extends upwards to the cluster computing layer, adding a dynamic hardware health assessment module and a high-speed cross-board data communication bus. Once an anomaly is detected on the current computing board, this application can immediately utilize the incremental checkpoints pre-stored during the safe period to agilely migrate and reconstruct the on-orbit task status to other healthy computing boards. In summary, this application provides a complete, dynamic, and fault-tolerant closed-loop technical solution encompassing orbit environment prediction, low-overhead incremental backup, and agile task migration.

[0070] The primary objective of this application is to address the serious shortcomings of existing spaceborne computer systems when performing complex computational tasks, such as wasted computing power and lagging protection due to traditional static fault-tolerance mechanisms. Specifically, this application aims to overcome the problem of the extreme occupancy of onboard memory bus bandwidth caused by fixed-frequency full state checkpoints, break the current situation of blind defense where the underlying hardware fault-tolerance strategy is disconnected from the external space physical environment, and solve the bottleneck of the inability to quickly restore task continuity when a single computing board encounters a severe single-event failure. Therefore, this application proposes an orbital periodic awareness fault-tolerance scheme for spaceborne computer systems, achieving high-availability computing in the high-energy radiation environment of space through deep collaboration of environmental awareness, low-power incremental backup, and cluster scheduling.

[0071] Figure 1 A schematic flowchart of an orbital period-aware fault-tolerant method for a spaceborne computer system according to an embodiment of this application is shown. Figure 1As shown, the method mainly includes: Step S1: Determine whether the satellite is in a safe orbit segment or a risky orbit segment based on the real-time acquired environmental radiation flux of the satellite's current orbit; Step S2: In response to determining that the satellite is in a safe orbit segment, perform incremental checkpoint data backup on the main computing board at a first frequency; Step S3: In response to determining that the satellite is in a risky orbit segment, perform incremental checkpoint data backup on the main computing board at a second frequency higher than the first frequency.

[0072] In one embodiment of this application, the method further includes: determining that the satellite is in a safe orbit segment when the ambient radiation flux is less than a first preset threshold; and determining that the satellite is in a risky orbit segment when the ambient radiation flux is greater than or equal to the first preset threshold.

[0073] Figure 2 A flowchart illustrating an orbital period-aware fault-tolerant method for a spaceborne computer system according to another embodiment of this application is shown. Figure 2 The method shown is executed by a spaceborne computer system. Figure 3 A schematic diagram of the modules of an onboard computer system according to an embodiment of this application is shown. Figure 3 As shown, the onboard computer system 200 includes at least one primary computing board 205 and at least one redundant backup computing board 206 connected via an intra-satellite high-speed data bus 207. The onboard computer system 200 also includes an ephemeris data receiving module 201, an independently powered fault-tolerant control board 203, and radiation-hardened non-volatile RAM (NVRAM) 204. The at least one primary computing board 205 and the at least one redundant backup computing board 206 can be heterogeneous computing boards. Each heterogeneous computing board integrates a high-performance processor and a large-capacity main memory. Furthermore, the onboard computer system 200 also includes an existing space radiation environment model 202. The space radiation environment model 202 can be built into the fault-tolerant control board 203. Figure 2 The main execution logic of the method shown is integrated in the fault-tolerant control board 203.

[0074] The following is combined with Figure 2 and Figure 3 The following provides a more detailed description of the specific execution process of the orbital period sensing fault-tolerant method for a spaceborne computer system according to embodiments of this application. Specifically, the environmental radiation flux in step S1 can be obtained in real time using the following method.

[0075] Specifically, such as Figure 2 The method shown may include the following steps:

[0076] Step S10: Real-time acquisition of the three-dimensional coordinates of the satellite's current orbit and acquisition of ephemeris data.

[0077] Here, the three-dimensional coordinates of the satellite's current orbit refer to the three-dimensional spatial position vector of the satellite's current orbit. Let the time variable be t, the three-dimensional spatial position vector can be denoted as... This three-dimensional spatial position vector It contains data in three spatial dimensions: longitude, latitude, and orbital altitude. This three-dimensional spatial position vector It can be done as follows Figure 3 The components of the onboard computer system 200 shown, such as a position sensing module (not shown), are used for data acquisition. The satellite's ephemeris data may include historical telemetry data from on-orbit single-event faults of the main computing board 205 of the onboard computer system 200 and satellite ephemeris characteristics, etc. The satellite's ephemeris data can be acquired through the ephemeris data receiving module 201 of the onboard computer system 200. The ephemeris data receiving module 201 can be any device or equipment, such as an onboard navigation receiver, capable of implementing the functions described above in this application.

[0078] Step S11: Based on the three-dimensional spatial position vector of the satellite's current orbit Calculate environmental radiation flux using ephemeris data. .

[0079] Among them, the space radiation environment model 202 of the onboard computer system 200 is configured as a three-dimensional spatial position vector based on the satellite's current orbit. Calculate environmental radiation flux The space radiation environment model 202 can be built into the fault-tolerant control board 203 of the onboard computer system 200.

[0080] Step S12: Query the environmental radiative flux in the three-dimensional coordinates of the satellite's current orbit in real time. And combined with single-particle flip section parameters Real-time calculation of the expected hardware failure rate of the main computing board 205 in the current time window (t) and the future time window (t+Δt). .

[0081] Among them, single-particle flip section parameters It can be derived from the factory calibration data of the main computing board 205 of the onboard computer system 200. △t can be selected based on actual operating conditions.

[0082] In some embodiments of this application, the expected hardware failure rate is... The calculation can be performed according to the following formula (1) or (2):

[0083] (1)

[0084] (2)

[0085] Let the energy of the fault-causing particle be E. and These are the minimum and maximum energy thresholds for fault-causing particles that can trigger a single-event flip or a single-event latch-up in the logic units inside the main computing board, respectively. This represents the three-dimensional spatial position vector of the satellite's current orbit. and All of these are the corresponding environmental radiation fluxes; These are the parameters for the single-particle flip-over section.

[0086] Through steps S10-S12, a precise mapping between the satellite's physical spatial location and the expected hardware failure rate of the onboard computer system can be established based on the orbital data acquisition and space radiation empirical model.

[0087] Step S13: Based on the expected hardware failure rate With safety threshold The comparison determines whether the satellite is in a "safe orbit segment" or a "risk orbit segment." Specifically, it determines whether the expected hardware failure rate is less than a safe threshold: when the expected hardware failure rate... Less than the safety threshold If the satellite is in a "safe orbit segment", proceed to step S14; otherwise, if it is in a "risk orbit segment", proceed to step S15.

[0088] Among them, the safety threshold It can be determined based on the computing power load of the spaceborne computer system 200 and the radiation resistance level of the devices in the spaceborne computer system 200.

[0089] Step S14: Issue a scheduling command to perform incremental checkpoint data backup on the primary computing board 205 at the first frequency.

[0090] Specifically, incremental checkpoint data backup includes performing an incremental backup operation and, after the incremental backup operation is completed, performing an incremental checkpoint save operation.

[0091] like Figure 5 As shown, the physical memory space 602 of the main computing board 205 is divided into a number of... physical memory page set .in, Each physical memory page in a set of physical memory pages has a fixed capacity, and all physical memory pages have the same capacity. Each physical memory page is denoted as The main computing board 205 has a hardware-level dirty page status record table configured inside its memory management unit. This table includes a physical memory page set. Each physical memory page in the table corresponds to a separate status bit in the dirty page status record table. .

[0092] Incremental backup operations are performed in the following manner:

[0093] At the start of the incremental backup operation, all status bits in the dirty page status record table configured inside the primary computing board 205 are reset to zero; and

[0094] During the incremental backup operation, when a write operation command is initiated on a specific physical memory page, the status bit corresponding to that specific physical memory page is set to "1".

[0095] For example, during the execution of regular arithmetic instructions by the main computing board 205, if the high-performance processor 601 of the main computing board 205 accesses a specific physical memory page... When a write operation command is initiated, the address interception logic in the memory management unit of the primary computing board 205 will immediately update the corresponding status bit. Set to the value "1".

[0096] The first frequency is the reciprocal of the first incremental backup cycle. The incremental backup cycle refers to the time interval between two adjacent incremental backup operations. In some embodiments of this application, the high-performance processor 601 of the primary computing board 205 can be, for example, a high-density FPGA, DSP, or NPU, a multi-core heterogeneous processor. In some embodiments of this application, the first frequency can be selected based on various parameters of the onboard computer system 200.

[0097] The incremental checkpoint saving operation includes:

[0098] The direct memory access controller in the onboard computer system 200 initiates and traverses the aforementioned dirty page status record table (i.e., accesses all contents of the aforementioned dirty page status record table); and

[0099] The direct memory access controller only fetches physical memory page data (dirty page data) with a status bit of "1" into the cache as an incremental context.

[0100] Specifically, the Direct Memory Access Controller (DMI) can combine these dirty page data and their corresponding address mappings, timestamps, task identifiers, and other metadata into a single incremental checkpoint. A single incremental checkpoint includes all physical memory pages with a current status bit of "1". By extracting only physical memory pages with a status bit of "1" into the cache as incremental context, the storage and transmission overhead caused by full checkpoint data backup can be reduced while ensuring the task context is recoverable. The fault tolerance controller can be a hardware timer or counter integrated within the fault tolerance control board 203. The fault tolerance controller can proactively trigger the DMI to start and traverse the aforementioned dirty page status record table to perform incremental checkpoint saving operations according to set conditions.

[0101] Assume the data capacity of a single physical memory page is constant. Total amount of data generated by a single incremental checkpoint data backup The sum of the modified physical memory page capacities is calculated using the following formula:

[0102] (3)

[0103] Total data volume generated based on a single incremental checkpoint data backup It can calculate the intra-satellite bus time required for the incremental checkpoint data backup process. .

[0104] Let the available transmission bandwidth of the onboard high-speed data bus 207 in the onboard computer system 200 be... Then the intra-satellite bus time The calculation formula is

[0105] (4)

[0106] Among them, available transmission bandwidth This refers to the effective bandwidth actually available for high-performance computing tasks after deducting protocol overhead, error correction coding, arbitration waiting, bus usage, data flow from other tasks, and incremental checkpoint data transmission. Through the above settings, this application can reduce the bus / storage link usage caused by data backup, thereby freeing up more available transmission bandwidth for high-performance computing tasks such as large-scale onboard model inference and high-resolution image processing.

[0107] Since most memory page state bits remain at zero during the "safe orbit phase" (i.e., the radiation-stable phase), the above formula mathematically proves that the method provided in this application can complete the computational state backup / retention with minimal time consumption, thereby maximizing the release of communication physical bandwidth for high-computing tasks (such as onboard large model inference, high-resolution image processing, etc.). Communication physical bandwidth is the theoretical or rated transmission capacity that the onboard high-speed data bus or storage interface can provide at the hardware level.

[0108] In summary, in incremental checkpoint data backup, the method provided in this application activates the dirty page bitmap function in the physical memory space of the primary computing board 205. Within a computing cycle, the corresponding status bit is only set to a valid state by the hardware when a write operation is required on a physical memory page. When the fault tolerance controller is triggered, the direct memory access controller traverses the dirty page status record table (dirty page bitmap) and asynchronously writes only the dirty page data with valid status bits into the radiation-hardened non-volatile memory (NVRAM) 204 in the onboard computer system 200 via the onboard high-speed data bus 207. The dirty page status record table is then cleared.

[0109] This application, by implementing a precise incremental checkpoint strategy during the "safe orbit segment," avoids the unnecessary occupation of the storage bus by massive amounts of mission status data, thereby reducing the I / O power consumption and backup downtime of the onboard computer system 200 by several times. This effectively reduces communication congestion on the onboard high-speed data bus 207 and the data throughput pressure on the storage bus when large computing tasks are in execution state retention.

[0110] The method provided in this application acquires the three-dimensional coordinates of the satellite's current orbit in real time and calculates the expected hardware failure rate. Then, based on the expected hardware failure rate, a scheduling command is issued to enable the main computing board of the onboard computer system to execute the corresponding backup strategy.

[0111] Step S15: Compare the expected hardware failure rate With danger alarm threshold Specifically, determining the expected hardware failure rate. Is it greater than or equal to the danger alarm threshold? When the expected hardware failure rate Greater than or equal to the danger alarm threshold If the satellite is in a "high-risk orbit segment," proceed to step S16; otherwise, if it is in a "low-risk orbit segment," proceed to step S17. In other words, when... When, proceed to step S16; when Then proceed to step S17.

[0112] Among them, danger alarm threshold It can be determined based on the computing power load of the spaceborne computer system 200 and the radiation resistance level of the devices in the spaceborne computer system 200.

[0113] This application uses a dynamic evaluation threshold to identify and classify the satellite's orbital environment with extreme precision, automatically determining whether the satellite is currently in a "safe orbital segment" of a stable radiation zone, a "low-risk orbital segment" about to cross an abnormal radiation zone, or a "high-risk orbital segment" of an abnormal radiation zone.

[0114] Step S16: Issue a scheduling command to cause the main computing board 205 of the onboard computer system 200 to enter the "early warning and error detection mode".

[0115] In the warning and error detection mode, perform the following operations:

[0116] Incremental checkpoint data backup is performed on the main computing board 205 at a second frequency greater than the first frequency. The second frequency can be 3.5 times, 4 times, or 4.5 times the first frequency, etc. Preferably, the second frequency can be at least 5 times the first frequency.

[0117] Priority protection is performed on components related to core computing tasks in the onboard computer system. For example, the fault-tolerant control board 203 can perform priority protection on computing units, memory pages and data paths related to core computing tasks, as well as suspend, reduce or migrate non-real-time computing tasks or low-priority computing tasks.

[0118] The fault-tolerant control board 203 increases the frequency of status detection and error checking of the primary computing board 205, and shortens the time window for health assessment of the primary computing board 205 (i.e., increases the frequency of health assessment); and

[0119] When the error count, health assessment score, or expected hardware failure rate continues to deteriorate, the fault tolerance control board 203 triggers a safety baseline snapshot read, incremental checkpoint replay, or backup computing unit takeover to reduce the impact of single-event upsets, transient failures, or local hardware degradation on task continuity.

[0120] Step S17: Issue a scheduling command to cause the main computing board 205 of the onboard computer system 200 to enter the "baseline operation mode".

[0121] In baseline running mode, perform the following operations:

[0122] Temporarily suspend or reduce the priority of non-real-time computing tasks on the main computing board 205;

[0123] Perform a full copy of the memory state on the primary compute board 205 to generate a full baseline checkpoint dataset. This will be used as a safety baseline snapshot for subsequent responses to harsh environments (mandatory safety baseline snapshot), which allows for rapid recovery of data provided later.

[0124] Incremental checkpoint data backup is performed on the main computing board 205 at a third frequency that is greater than the first frequency and less than the second frequency. The third frequency can be 2 times, 2.5 times, or 3 times the first frequency, etc.

[0125] The baseline operating mode is configured to proactively enhance the fault tolerance of the primary computing board when risks escalate but have not yet reached the danger alarm threshold. In this mode, by increasing the frequency of incremental checkpoint data backups from a first frequency to a third frequency and pre-generating a full baseline checkpoint data set, a safe baseline can be provided for the rapid recovery of data that may be needed for subsequent high-risk track segments.

[0126] Through the steps described above, this application achieves a leap from passive defense to predictive fault tolerance: by dynamically identifying low-risk orbital segments approaching high-risk segments, the onboard computer system 200 can establish a safety baseline in advance before severe environmental degradation, thereby greatly reducing the risk of precipitous data loss under extreme radiation environments. This mechanism can maximize the high-performance computing potential of the onboard computer system 200 when the satellite is in a safe orbital segment, while ensuring the safety of the fault-tolerant baseline.

[0127] The full memory state refers to the complete memory image information required to restore the target task, including at least the physical memory pages, virtual address mappings, heap, stack, critical kernel context, page table information, and necessary device mapping states corresponding to the target task. For cached or temporary states, recording, flushing, or invalidation can be selected based on the consistency requirements for recovery.

[0128] In some embodiments of this application, preferably, in baseline operating mode, the following operations are also performed: when At that time, a full copy of the memory state is performed on the primary computing board 205 to generate a full baseline checkpoint data set. .

[0129] In some embodiments of this application, preferably, the orbital period sensing fault-tolerant method for a spaceborne computer system according to the embodiments of this application is executed at a preset fixed frequency or a variable frequency.

[0130] Figure 4 A schematic diagram illustrating the expected hardware failure rate according to one embodiment of this application is shown. Figure 4 As shown, when the expected hardware failure rate Less than the safety threshold At that time, the main computing board 205 of the onboard computer system 200 performs incremental checkpoint data backup at the first frequency; when the expected hardware failure rate... Greater than or equal to the danger alarm threshold At that time, the main computing board 205 of the onboard computer system 200 enters the "early warning and error detection mode"; when When the expected hardware failure rate approaches the danger alarm threshold, the main computing board 205 of the onboard computer system 200 enters the "baseline operation mode".

[0131] Furthermore, to improve the adaptability of the above method to complex tasks, this application introduces a task sensitivity coefficient weight. Statistical correction factor for on-orbit historical faults In some embodiments of this application, the method may further include the following steps:

[0132] Weighted based on task sensitivity coefficient Statistical correction factor for on-orbit historical faults Calculate the dynamic orbit risk index .

[0133] Specifically, the dynamic orbital risk index is calculated using the following formula. :

[0134] (5)

[0135] in, As the weight of the task sensitivity coefficient, This is a correction factor for on-orbit historical fault statistics. Expected hardware failure rate. Task sensitivity coefficient weight. This can be pre-configured based on mission type, real-time requirements, mission priority, payload data importance, and mission interruption tolerance time, or it can be read from the satellite mission scheduling table or mission description file. On-orbit historical fault statistical correction factor. It can be obtained by comprehensively updating based on the fault logs, error correction code counts, restart counts, single-event records, health monitoring data, and historical statistical models accumulated during the onboard computer system's operation in orbit. (Task sensitivity coefficient weight) Statistical correction factor for on-orbit historical faults The parameters can be preset in the fault-tolerant control board 203 and can be periodically corrected by ground remote control commands or on-orbit statistical results.

[0136] This step involves using the dynamic orbital risk index. The system compares the risk level with preset threshold values ​​in real time, driving the underlying fault-tolerant controller state machine of the onboard computer system 200 to seamlessly switch between corresponding defense modes. Specifically, the underlying fault-tolerant controller state machine periodically calculates the dynamic orbital risk index. Or expected hardware failure rate And compare it with the corresponding threshold; when the dynamic orbit risk index Or expected hardware failure rate When the corresponding threshold is exceeded, the underlying fault-tolerant controller state machine first completes the current checkpoint submission and metadata write to disk, and then adjusts the triggering frequency of incremental checkpoint saving operations, the frequency of state detection and error verification, task priority and resource mapping relationship; for scenarios that need to be taken over, the backup computing power unit reads the most recent full baseline checkpoint and subsequent incremental checkpoints, and continues to execute the task after reconstructing the task context, thereby reducing task interruption time.

[0137] The defense modes can include at least: for example, a baseline operation mode and an early warning and error detection mode. The risk level threshold and the corresponding defense mode can be set in the onboard computer system 200, preferably stored in the threshold parameter table or state machine configuration table of the fault tolerance control board 203, and can be updated via ground remote control commands.

[0138] In some embodiments of this application, the main computing board 205 of the spaceborne computer system 200 may be composed of a single processor board or a heterogeneous multi-core processor cluster.

[0139] In some embodiments of this application, the method may further include the following steps:

[0140] When a satellite enters a "high-risk orbital segment", a cross-node health assessment (monitoring) and agile mission migration are performed.

[0141] A global health monitoring matrix for all computing boards (including primary and backup computing boards) of the onboard computer system 200 is constructed, maintained, and periodically updated in the fault-tolerant control board 203. In other words, the fault-tolerant control board 203 continuously maintains the data structure and update mechanism of this global health monitoring matrix. Specifically, the global health monitoring matrix can reside permanently in the fault-tolerant control board 203 or its associated storage area and be updated according to a set period or event-triggered method. When the satellite is in a "safe orbit segment," a longer set period (i.e., a lower update frequency) can be used; when the satellite is about to enter or has already entered a "risk orbit segment," a shorter set period (i.e., a higher update frequency) can be used.

[0142] For all computing boards, the first Each computing board is defined with a real-time health score of [missing information]. Among them, the health score is Based on the initial full score benchmark value Deductions are made in real-time. The specific value of the deduction item can be determined by the frequency of occurrence of various abnormal event types and their corresponding penalty weights. Let the first... The number of times the exception event occurs within a specific time sliding window is The penalty weight constant set for this type of abnormal event is: The total number of exception types is Then the real-time health score The calculation formula is:

[0143] (6)

[0144] No. The number of times a type of exception event occurs within a specific time sliding window. This data can be acquired from the error detection module, ECC / EDAC statistics module, bus error counter, mission watchdog, and temperature / voltage monitoring module within the onboard computer system 200. (Penalty weight constant) and the total number of exception types The parameters can be pre-stored in the parameter configuration table of the fault-tolerant control board 203 and can be updated according to on-orbit operation data or ground commands.

[0145] The abnormal event types cover single-bit correctable errors, multi-bit uncorrectable errors, and heartbeat packet loss events reported by the low-level error detection module of the onboard computer system 200. Among them, uncorrectable errors and continuous heartbeat loss events are assigned extremely high penalty weight constants by the system.

[0146] The real-time health score of the main computing board performing core computing tasks in the onboard computer system 200 When the load falls below the set lower safety threshold (THL), the task migration logic is automatically triggered. This involves cutting off the communication link of the primary computing board that is experiencing the anomaly and selecting the redundant standby computing board 206 with the highest current score and available computing resources from the aforementioned global health monitoring matrix as the takeover node. The onboard computer system 200 may include multiple primary computing boards 205 and multiple redundant standby computing boards 206.

[0147] In the embodiments of this application, core computing tasks typically include computing tasks that maintain the basic functions of the satellite in orbit, computing tasks that cannot be interrupted in the mission objectives, and computing tasks that are marked as important by the user.

[0148] The takeover node reads the most recently generated full baseline checkpoint data set from the radiation-hardened non-volatile memory 204 via the onboard high-speed data bus 207. It also replays the data from the full baseline checkpoint dataset in chronological order, either by timestamp or sequence number. The subsequent collection of all incremental checkpoint data For duplicate addresses, the later-generated incremental checkpoint is used. The above process essentially uses the most recent full baseline checkpoint data set. To restore the baseline, incremental checkpoints are replayed sequentially according to their generation time. Dirty page data from each incremental checkpoint is then written back to the corresponding address, thus reconstructing the latest complete task context. The takeover node utilizes hardware address reconstruction logic to write the incremental checkpoint data into this full baseline checkpoint data set. In the corresponding memory address, and generate the latest complete task context. The logical merging process is represented as follows:

[0149] (7)

[0150] The takeover node first sends the latest complete task context mentioned above. The instruction is loaded into its own physical memory array and registers at all levels, then the program counter is reset to point to the correct execution location, and finally the instruction pipeline is restored to normal operation. This process is completed at the hardware level, ensuring that task switching is completely transparent to the user and seamless (i.e., achieving seamless switching).

[0151] In one embodiment of this application, when a satellite enters a "high-risk orbital segment," the method provided in this application may further include the following steps: increasing the abnormal monitoring level of the hardware; controlling the error detection and correction code inside the main computing board 205 that is performing a high-computing task to enter a high-frequency working state; controlling the fault-tolerant control board 203 to also enter a high-frequency working state for the heartbeat monitoring of the main computing board 205; when the fault-tolerant control board 203 detects that the main computing board 205 has experienced continuous heartbeat loss, the error detection unit reports multiple bit flips exceeding the error correction limit, or a single-event latch-up occurs causing a surge in current, etc., it immediately executes the task migration logic.

[0152] Specifically, the task migration logic can be executed in the following ways:

[0153] First, the fault-tolerant control board 203 sends a hard reset command to the primary computing board 205 or directly cuts off its local high-voltage power supply to prevent erroneous data from spreading on the bus. Second, the fault-tolerant control board 203 queries the global health monitoring matrix and wakes up the redundant backup computing board 206 with the best status. Then, the redundant backup computing board 206 retrieves the most recently generated full baseline checkpoint data set from the radiation-hardened non-volatile memory (NVRAM) 204 through the intra-satellite high-speed data bus 207. The dirty page data contained in the subsequent incremental checkpoints are superimposed onto the full baseline checkpoint data set according to the order in which the subsequent incremental checkpoints are generated. Finally, the redundant backup computing board 206 completes the reverse merging of the task context and the reconstruction of the program counter in its own physical memory, seamlessly restarts the damaged task and continues to output the calculation results.

[0154] This application completely breaks through the lag of traditional single-node reset and rollback by combining hardware and software cross-board task migration logic, enabling the onboard computer system to maintain the continuity and high availability of core computing services even when facing severe single-event breakdown faults, thus building a seamless level of task continuity assurance.

[0155] The orbital cycle-aware fault-tolerant method for onboard computer systems provided in this application not only offers single-board-level data backup but also constructs a task takeover network at the heterogeneous computing power cluster level. When the satellite is in a high-risk orbital segment, the method provided in this application will periodically poll the watchdog status and error detection and correction code alarm rate of each computing power board. Once it is determined that the current computing power board has an uncorrectable operational error or abnormal hardware current due to sudden strong radiation, a physical isolation command will be immediately issued to prevent the error from spreading. At the same time, the method provided in this application will automatically wake up the healthy redundant computing power boards in the cluster through the intra-satellite high-speed data bus, quickly extract the full set of baseline checkpoint data saved during the most recent safe period, and complete the precise reverse merging and reconstruction of the task context in the memory space of the healthy redundant computing power board, ultimately guiding the computing task to seamlessly take over execution on the new node.

[0156] In some embodiments of this application, the onboard computer system further includes a hardware health dynamic assessment module and a cross-board high-speed data communication bus.

[0157] The orbital period-aware fault-tolerant method for spaceborne computer systems according to this application can be applied to spaceborne computing clusters.

[0158] In one embodiment of this application, a computer device is also provided. This computer device is configured to execute the orbital period-aware fault-tolerant method for a spaceborne computer system according to the above embodiments of this application. The computer device can be deployed in a spaceborne computer system. For example, the computer device can be integrated on the main computing board 203 in a spaceborne computer system 200.

[0159] In another embodiment of this application, a computer program product is also provided, which stores a computer program or executable instructions. When the computer program or executable instructions are executed by a processor, the technical solution described in the foregoing embodiments is implemented. The implementation principle is similar and will not be repeated here. This computer program product can be, but is not limited to, the following forms: a computer-readable storage medium, a downloadable program product, a program product embedded in a chip carrying program propagation signals, etc. The computer program product can be embodied in a computer-readable storage medium, including: a USB flash drive, a portable hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, an optical disk, a solid-state drive, a memory card, etc. When a computer program is stored on the storage medium, the processor reads and executes the computer program, thereby implementing the method according to the embodiments of this application. The computer program product can also be embodied in a program file that can be downloaded via a network, including installation packages, image files, compressed packages, executable files, script files, etc. After a user downloads the program product to a local computer, server, or terminal device via the Internet or a local area network, the processor executes the program through installation, loading, or running operations to achieve the corresponding function. The computer program product can also be a program product embedded in a chip, such as firmware embedded in a microcontroller (MCU), field-programmable gate array (FPGA), application-specific integrated circuit (ASIC), etc. After the chip powers on, it automatically loads and executes the computer program, enabling the chip to perform its corresponding functions. The computer program product can also be a propagation signal carrying the program, such as a carrier wave, digital signal, or optical signal, in which computer program instructions are modulated. This signal can be transmitted via wired networks, wireless networks, fiber optic links, etc. The receiving device receives and demodulates the signal, then extracts and executes the computer program from it.

[0160] The orbital period sensing fault-tolerant method, apparatus, and computer program product for a spaceborne computer system according to the embodiments of this application have the following beneficial technical effects:

[0161] (1) The system’s redundancy and backup overhead is greatly reduced: By executing a precise incremental checkpoint strategy in the “safe orbit segment”, the invalid occupation of the storage bus by massive task status data can be avoided, thereby reducing the I / O power consumption and backup downtime of the onboard computer system by several times.

[0162] (2) Achieving a leap from passive defense to predictive fault tolerance: By using the space radiation environment model to dynamically identify high-risk orbital segments, the onboard computer system can build a safety baseline in advance before the environment deteriorates severely, which greatly reduces the risk of data cliff loss under extreme radiation environment.

[0163] (3) A seamless task continuity guarantee was constructed: Through the cross-board task migration mechanism combining hardware and software, the lag of traditional single-node reset and rollback was completely broken, so that the onboard computer system can still maintain the continuity and high availability of core computing services when facing severe single-event breakdown faults, thus constructing a seamless task continuity guarantee.

[0164] References to "various embodiments," "some embodiments," "one embodiment," or "embodiment," etc., in this specification refer to a specific feature, structure, or property described in connection with the said embodiment, included in at least one embodiment. Therefore, the appearance of the phrases "in various embodiments," "in some embodiments," "in one embodiment," or "in an embodiment," etc., throughout this specification does not necessarily refer to the same embodiment. Furthermore, specific features, structures, or properties can be combined in any suitable manner in one or more embodiments. Therefore, a specific feature, structure, or property shown or described in connection with one embodiment can be combined, in whole or in part, with features, structures, or properties of one or more other embodiments without limitation, provided that the combination is not illogical or inoperable.

[0165] The terms "comprising," "having," and similar expressions used in this specification are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to these processes, methods, products, or apparatuses. Furthermore, the elements in the accompanying drawings are for illustrative purposes only and are not drawn to scale.

[0166] Although this application has been described through preferred embodiments, it is not limited to the embodiments described herein, and various changes and modifications are included without departing from the scope of this application.

Claims

1. A fault-tolerant method for orbital period awareness in a spaceborne computer system, wherein, The onboard computer system includes a main computing board, and the method includes: The satellite is determined to be in a safe orbit or a risky orbit based on the real-time acquired environmental radiation flux of its current orbit. In response to determining that the satellite is in the safe orbit segment, incremental checkpoint data backup is performed on the primary computing board at a first frequency; In response to determining that the satellite is in the risky orbit segment, the incremental checkpoint data backup is performed on the primary computing board at a second frequency higher than the first frequency.

2. The method according to claim 1, wherein, Determining whether a satellite is in a safe or risky orbit segment based on the real-time acquired environmental radiation flux of its current orbit includes: The system collects the three-dimensional coordinates of the satellite's current orbit in real time and obtains ephemeris data. Based on the three-dimensional coordinates and the ephemeris data, calculate the environmental radiation flux; The ambient radiation flux is queried in real time, and based on the ambient radiation flux and the single-particle flip section parameters of the main computing board, the expected hardware failure rate of the main computing board in the current time window and future time windows is calculated in real time. The satellite is determined to be in the safe orbit segment or the risk orbit segment based on a comparison between the expected hardware failure rate and a preset safety threshold.

3. The method according to claim 2, further comprising: When it is determined that the satellite is in the risky orbit segment, the expected hardware failure rate is compared with a predetermined danger threshold; When the expected hardware failure rate is less than the danger alarm threshold, a scheduling instruction is issued to cause the primary computing board to perform data backup in baseline operating mode.

4. The method according to claim 3, wherein, The baseline operating modes include: Temporarily suspend or reduce the priority of non-real-time computing tasks on the main computing board; Perform a full copy of the main computing board's memory state to generate a full baseline checkpoint dataset, and use this as a security baseline snapshot for rapid data recovery in subsequent deployments; and The incremental checkpoint data backup is performed on the main computing board at a third frequency that is greater than the first frequency and less than the second frequency.

5. The method according to claim 3, further comprising performing the following operation when the expected hardware failure rate is greater than or equal to the danger alarm threshold: The incremental checkpoint data backup is performed on the main computing board at the second frequency; Priority protection is applied to components related to core computing tasks in the onboard computer system. Suspend, reduce the frequency of or migrate non-real-time computing tasks or low-priority computing tasks on the main computing board; Increase the frequency of status detection and error checking of the main computing board; as well as Shorten the time window for health assessment of the main computing board.

6. The method according to claim 3, further comprising: A global health monitoring matrix is ​​constructed and updated periodically according to a set period. The global health monitoring matrix includes the health score of each computing board in all computing boards in the onboard computer system. When the expected hardware failure rate is greater than or equal to the danger alarm threshold, compare the health score of the first primary computing board that is executing the core computing task with the lower limit safety threshold. When the health score of the first primary computing board falls below the lower safety threshold, the task migration logic is automatically triggered. The task migration logic includes: Disconnect the communication link of the first primary computing board; Select the redundant standby computing board with the highest current health score and idle computing resources from the global health monitoring matrix as the takeover node; Read the most recently generated full baseline checkpoint data set from the first primary computing board to reconstruct the latest complete task context in the redundant standby computing board; and The core computing task continues to be executed using the redundant backup computing boards.

7. The method according to claim 1, wherein, The incremental checkpoint data backup includes: Perform an incremental backup operation as follows: At the start of the incremental backup operation, all status bits in the dirty page status record table configured inside the primary computing board are reset to zero, wherein each status bit corresponds to a physical memory page in the physical memory space of the primary computing board; and During the incremental backup operation, when a write operation instruction is initiated on a specific physical memory page, the status bit corresponding to that specific physical memory page is set to "1"; and After the incremental backup operation is completed, perform the incremental checkpoint save operation as follows: The dirty page status record table is traversed, and only physical memory page data with a status bit of "1" are extracted as incremental context into the cache of the primary computing board.

8. The method according to claim 1, further comprising: The dynamic orbit risk index is calculated based on the weight of the mission sensitivity coefficient and the correction factor for on-orbit historical fault statistics. as well as The dynamic orbit risk index is compared with preset risk level thresholds respectively; as well as Based on the comparison results, the backup mode adopted by the primary computing board for performing data backup is determined.

9. A spaceborne computer system comprising a controller configured to perform the method according to any one of claims 1-8.

10. A computer program product having a computer program or instructions stored thereon, which, when executed, implement the method according to any one of claims 1-8.

Images