Satellite computer operating system fault tolerance method

Abstract

The application relates to the technical field of spacecraft computers, and discloses a satellite-borne computer operating system fault-tolerant method, which comprises the following steps: step 1, creating a main operating system partition, a backup operating system partition and a boot partition in a solid-state storage device, the main operating system partition and the backup operating system partition are installed with the same version of a general operating system, and the backup operating system partition stores a compressed mirror file containing complete data of the main operating system partition; and step 2, deploying customized boot management software in the boot partition, and configuring a startup mark file storage path and a maximum retry number threshold of the boot management software. The operating system self-sensing and self-switching technology provided by the application can realize the switching function of the operating system under the condition that the satellite-borne computer is operated on-orbit without manual operation, can ensure that the satellite-borne computer can normally start and operate under extreme conditions, and will not be directly lost.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of spacecraft computer, in particular to a satellite-borne computer operating system fault-tolerant method. BACKGROUND

[0002] With the continuous improvement of the informatization degree of the satellite industry, more and more payloads using general operating systems in satellites, satellite-borne computers are typical representatives. Usually, the operating system is deployed in a solid state disk (SSD), and the SSD as a storage device has abnormal problems such as data flipping and bad blocks in the space environment, which will cause the operating system deployed in the SSD to be damaged.

[0003] In the ground use scenario, the operating system damage can be recovered by the operation and maintenance personnel through the installation medium to reinstall the operating system, but the satellite as an unattended environment has no way to use the conventional means to reinstall the operating system, resulting in that once the operating system is damaged, the payload function will be unavailable, causing significant loss to the satellite asset. At present, the satellite field mostly uses embedded operating systems or real-time operating systems, and the related fault-tolerant technology is based on the foregoing operating systems, and there is little research on the fault-tolerance of general operating systems.

[0004] Technical pain points of the prior art:

[0005] The fault-tolerant technology of the traditional payload embedded operating system or real-time operating system is not applicable in the general operating system.

[0006] The cost of supporting operating system reinstallation on the satellite is high.

[0007] The traditional single-bit error correction mechanism cannot cope with the multiple file association damage scenario. When the operating system key configuration file and dynamic link library occur bit flipping at the same time, the existing verification method cannot guarantee the complete recovery of the system. The manual intervention mechanism relied on by the ground operation and maintenance mode is completely invalid in the space unattended environment, resulting in that the system failure cannot be repaired in time.

[0008] Therefore, the present application provides a satellite-borne computer operating system fault-tolerant method to solve the above problems. SUMMARY

[0009] In view of the deficiencies of the prior art, the present application provides a satellite-borne computer operating system fault-tolerant method to solve the problems in the background art.

[0010] To achieve the above purpose, the present application realizes the following technical scheme: a satellite-borne computer operating system fault-tolerant method, comprising:

[0011] Step 1, creating a main operating system partition, a backup operating system partition and a boot partition in the solid state storage device, the main operating system partition and the backup operating system partition installing the same version of general operating system, the backup operating system partition storing a compressed image file containing complete data of the main operating system partition;

[0012] Step 2, deploying a customized boot management software in the boot partition, and configuring a startup flag file storage path and a maximum retry threshold of the boot management software;

[0013] Step 3, when the on-board computer is powered on, the boot management software creates a startup flag file in the startup flag file storage path and loads the main operating system partition;

[0014] Step 4, deleting the startup flag file when the main operating system partition starts successfully, and retaining the startup flag file and triggering the on-board computer to restart when the main operating system partition fails to start;

[0015] Step 5, the boot management software detects the number of times of existence of the startup flag file during the restart process, and modifies the partition loading parameter to point to the backup operating system partition when the number of times of existence reaches the maximum retry threshold;

[0016] Step 6, the backup operating system partition accesses the compressed image file after starting, the compressed image file being generated by a bit-level copy method and compressed by an LZ4 algorithm;

[0017] Step 7, the backup operating system partition writes the decompressed compressed image file into the main operating system partition, and performs the on-board computer restart operation after completing the data coverage of the main operating system partition.

[0018] Preferably, the main operating system partition and the backup operating system partition in step 1 adopt an ext4 file system format, the boot partition adopts a FAT32 file system format, and the capacity of the main operating system partition accounts for 30%-40% of the total capacity of the solid state storage device;

[0019] The determination conditions of the main operating system partition failure in step 4 include at least one of the following: kernel file hash check mismatch, root file system mounting timeout, and system service initialization failure.

[0020] Preferably, the compressed image file in step 6 is generated by adopting a fixed block size of 4MB for data blocking, the compression level is set to 9 levels, and the compressed image file is stored in the / backup directory of the backup operating system partition;

[0021] The compressed image file in step 6 contains metadata check information, and the metadata check information contains a CRC32 check value of an original partition, an LBA address mapping table and a compressed block index table.

[0022] The step 7 is performed before the storage medium health state detection, and the detection items include bad block quantity statistics, remaining life percentage calculation, and read / write error rate analysis. If any detection item exceeds the preset threshold, the data overwrite operation is stopped.

[0023] After the step 7 is completed, a recovery completion status word is sent to the telemetry system of the satellite computer, and the status word includes a recovery timestamp, a written data volume, and a verification result.

[0024] Preferably, in the step 1, creating the main and backup operating system partitions and the storage compressed image file further includes:

[0025] Sub-step 1.1, calculating the main operating system partition capacity according to the total capacity of the solid state storage device, wherein the main operating system partition capacity is calculated as follows:

[0026] S main = α·S total ,

[0027] wherein S main is the main operating system partition capacity, S total is the total capacity of the solid state storage device, and α is a preset proportion coefficient.

[0028] Sub-step 1.2, creating the main and backup operating system partitions using the parted tool according to the capacity value calculated in sub-step 1.1,

[0029] the main operating system partition has a starting offset of 1 MiB and a termination offset of S main ,

[0030] the backup operating system partition has a starting offset of S main + 1 MiB and a capacity equal to S main ,

[0031] the boot partition is created at the end of the solid state storage device and has a capacity of 512 MiB:

[0032]

[0033] wherein MiB is a binary megabyte.

[0034] Sub-step 1.3, performing bit-level replication on the main operating system partition to generate an original image file, using the LZ4 algorithm for compression with a block size of 4 MB and a compression level of 9, storing the compressed image file to the / backup directory of the backup operating system partition, calculating the SHA-256 hash value of the compressed image file and storing it as a verification file, and generating the compressed image file of the main operating system partition:

[0035]

[0036] wherein B i is the i-th 4MB data block, LBA i is the logical block address, || is data splicing, H img is the hash value of the mirror file, is the exclusive or operator, n is the total number of data blocks, and SHA256(·) is the 256-bit version of the secure hash algorithm.

[0037] Preferably, in step 2, deploying the customized boot management software further comprises:

[0038] Sub-step 2.1, compiling the boot management software based on the GRUB2.06 source code, including ext4 file system support module, GPT partition identification module and chain loading module, the module set M contains at least fs ext4 , part GPT , chainloader three groups of essential modules.

[0039] M = {m1, m2,..., m i}, m i ∈ {fs ext4 , part GPT , chainloader},

[0040] wherein M is the kernel module set required when compiling the boot management software, fs ext4 is the kernel module of the boot management software, part GPT is the partition management module of the boot management software, and chainloader is the chain loader module.

[0041] m i is a functional module, which contains at least fs ext4 , part GPT , chainloader three groups of essential modules.

[0042] Sub-step 2.2, setting the startup flag file storage path to / boot / start flag in the grub.cfg configuration file of the boot partition, and calculating the maximum retry threshold N retry :

[0043]

[0044] wherein L PE is the number of program / erase cycles of the solid state storage device, and N retry is the maximum retry threshold.

[0045] Sub-step 2.3, execute configuration verification script, check if the startup flag file storage path exists and has write permission, verify if the maximum retry number threshold is an integer between 3 and 5, trigger a configuration error alarm if any condition is not met:

[0046]

[0047] wherein p is the path variable, P flag is the complete storage path of the startup flag file, dir exist (p) is the path existence verification function;

[0048]

[0049] When the value of dir exist (p) is 1, it indicates that the path p exists and has write permission;

[0050] When the value of dir exist (p) is 0, it indicates that the path p does not exist or is not writable.

[0051] Preferably, in step 3, the boot management software creates a startup flag file and loads the main operating system partition further comprises:

[0052] Sub-step 3.1, check if the boot partition mounting path D boot exists and the remaining space is not less than 1MB, if the verification fails, trigger the path repair process:

[0053] V path = dir exist (D boot ) ∧ free space (D boot ) ≥ S min ,

[0054] wherein V path is the path validity verification function, dir exist is the directory existence detection function, free space is the storage space detection function, D boot is the boot partition mounting path, and S min is the minimum reserved space;

[0055] Sub-step 3.2, create an encrypted startup flag file, use AES-GCM algorithm to encrypt to generate a startup flag file F flag , the encrypted content contains the current UTC timestamp and an arbitrary number, and the encryption key K sec is generated by the TPM module of the on-board computer:

[0056] F flag = AES Encrypt(T boot ||H nonce ,K sec ),

[0057] wherein F flag is an encrypted boot flag file, AES Encrypt (·) is an encryption function, T boot is a boot timestamp, H nonce is a 256 arbitrary number, K sec is a session key generated by a hardware security module;

[0058] Sub-step 3.3, loading the main operating system partition and verifying integrity, calling grub load function of GRUB to load the main operating system partition P main , performing kernel file SHA-256 check and ext4 file system mounting verification, any verification failure, return error code:

[0059]

[0060] wherein grub load (·) is a partition loading function, P main is the main operating system partition identifier, sha256 check (·) is a hash check function, ext4 mount is a file system mounting operation, boot is a boot partition technical parameter, and vmlinuz is a kernel file specification.

[0061] Preferably, in step 4, the main operating system boot state processing further comprises:

[0062] Sub-step 4.1, implementing multi-dimensional boot monitoring, monitoring the main operating system partition mounting time and system service state, wherein the mounting time T mount is started by calling the ext4 mount function, and the service state detection covers sshd, syslogd, and crond three groups of services:

[0063]

[0064] wherein T mount is the mounting time, P main is the main operating system partition identifier, ext4 mount is the file system mounting operation, S init is the system service initialization failure counter, s i is the running state of the i-th service, δ is the service state judgment function, δ(s i ) is the quantitative evaluation result of the i-th service state, and m is the total number of key system services monitored.

[0065] Sub-step 4.2, performing layered failure judgment, when detecting that the kernel file hash value H kernel is inconsistent with the pre-stored reference value H golden , or the root file system mounting time exceeds T max , or the number of critical service initialization failures S init ≥3, it is determined that the startup fails:

[0066]

[0067] Wherein, F is the startup failure judgment flag, H kernel is the SHA-256 hash value of the current kernel file, H golden is the pre-stored kernel file reference hash value, T max is the root file system mounting timeout threshold;

[0068] Sub-step 4.3, triggering the state response mechanism, deleting the startup flag file F flag when the startup is successful and recording the normal state, and keeping F flag when the startup fails and triggering the on-board computer hardware reset:

[0069]

[0070] Wherein, R(F) is the state response function, delete(F flag ) is the operation instruction of deleting the startup flag file, log status (OK) is the startup success record written to the system log, keep(F flag ) is the control instruction of keeping the startup flag file, and reboot(·) is the hardware reset triggering function.

[0071] Preferably, in step 5, the boot management software detects the startup flag and switches the partition, which further comprises:

[0072] Sub-step 5.1, decrypting and verifying the startup flag file, using the key K sec stored by the hardware security module to decrypt the startup flag file F flag , and verifying that the deviation of the timestamp T boot from the current time T now does not exceed 5 minutes:

[0073]

[0074] Wherein, D flag is the decrypted startup flag file content, V ts is the timestamp verification result, AES Decrypt (·) is the decryption function based on the AEC-GCM algorithm, and verifytimestamp (·) is a timestamp verification function, T now is the current time, ΔT max is the maximum time deviation;

[0075] Sub-step 5.2, count the number of valid start flags, traverse all encrypted flag files under the / boot directory, and count the number of valid flag files C retry , the effective condition is that the timestamp verification is passed and the file content hash value matches the metadata:

[0076]

[0077] where C retry is the effective retry count counter, δ(F i ) is a characteristic function,

[0078] hash match(·) is a hash match verification function;

[0079] Sub-step 5.3, execute partition switching decision, when C retry ≥ N retry , modify the GRUB environment variable to set the root partition to the backup operating system partition, and update the boot configuration file:

[0080]

[0081] where N retry is the maximum retry threshold,

[0082] set root=(hd0,gpt2) is a GRUB environment variable setting command, hd0W2 the first block hard disk device, gpt2 is the second partition in the GPT partition table,

[0083] update-grub-output= / boot / grub / grub.cfg is a boot configuration update command, output is the specified configuration file path.

[0084] Preferably, in step 6, accessing and processing the compressed image file further comprises:

[0085] Sub-step 6.1, perform multi-level integrity verification, verify that the compressed image file metadata CRC32 check value V meta is consistent with the pre-stored value C store , and verify the SHA-256 hash value V block of the data before decompression block by block:

[0086]

[0087] where V metaFor metadata verification results, CRC32(·) is the cyclic redundancy check algorithm, V block For the data block-level verification result, B i For the i-th original data block, SHA256(·) is a secure hash algorithm, H i M is a pre-stored hash base value. head For image file header metadata, C store For pre-stored verification values;

[0088] Sub-step 6.2: Decompress and reconstruct the original image in blocks. Based on the compressed block index table, use the LZ4 algorithm to decompress the data in 4MB blocks and reconstruct the original image file D. raw :

[0089]

[0090] Where, D raw For the original mirror data of the reconstruction, LZ4 decompress For LZ4 decompression operations, C j For the j-th compressed block, S j This corresponds to the block size;

[0091] Sub-step 6.3: Perform address mapping conversion. Referring to the LBA address mapping table, convert the decompressed data block D... k Write the corresponding logical block address L k Complete the reconstruction of the primary partition data:

[0092]

[0093] Among them, write lba For logical block addressing write operations, k is the logical block index, and L is the logical block index. k For logical block address, D k For the corresponding data block.

[0094] Preferably, step 7, performing data overwrite and system restart, further includes:

[0095] Sub-step 7.1: Perform a storage media health assessment, calculate the storage media health index H. When H ≥ 0.7, data overwrite operations are allowed; otherwise, trigger an alarm and abort the operation.

[0096]

[0097] Where w1, w2, and w3 are weighting coefficients, H is the storage medium health index, and B... bad B represents the number of marked bad blocks. total C represents the total number of blocks in the storage medium. PE For the current cumulative programming / erase cycles, C maxE is the maximum allowed number of program / erase cycles rate E is the current read / write error rate max E is the maximum allowed read / write error rate threshold

[0098] Sub-step 7.2, performing secure erasing and data writing, partition P of the main operating system main Performing secure erasing, writing decompressed data D block by block according to the LBA address mapping table k Immediately performing read verification for each written 1-bit data block:

[0099]

[0100] wherein, secure erase (·) is a secure erasing function, P main is the main operating system partition identifier, k is the number of logical blocks, N is the total number of data blocks, swrite block (·) is a data block writing function, verify block (·) is a data block verification function, L k is the logical block address, D k is the corresponding data block

[0101] Sub-step 7.3, generating a restart control signal, counting the success rate of writing, sending a restart instruction when the success rate is greater than or equal to 99.9%, otherwise generating an error report and uploading it through the telemetry system:

[0102]

[0103] wherein, R is a restart control signal, reboot() is a hardware restart, alert() is an error report, success rate is the success rate of writing.

[0104] The present application provides a satellite computer operating system fault-tolerant method. It has the following advantages:

[0105] 1. The operating system self-awareness and self-switching technology provided by the present application can provide switching function of the operating system under the condition of unattended operation of the satellite computer in orbit, and can ensure that the satellite computer can operate normally under extreme conditions, and will not be directly lost.

[0106] 2. The operating system self-repairing technology provided by the present application can provide repair function of the operating system under the condition of unattended operation of the satellite computer in orbit, and can ensure that the satellite computer can recover function after the operating system error, and protect satellite assets.

[0107] 3. The application adopts intelligent fault detection and health assessment linkage self-repairing technology, realizes autonomous fault-tolerant technology effect in unattended environment, compared with single bit error correction and artificial operation and maintenance mechanism, solves the defects of multi-file group damage and space environment cannot be artificially intervened, through starting flag dynamic counting and medium health degree grading evaluation model, when detecting key file group abnormality, automatically triggers partition switching and data reconstruction, forms a closed loop self-healing system. BRIEF DESCRIPTION OF DRAWINGS

[0108] Figure 1 is a flowchart of the application;

[0109] Figure 2 is a partition diagram of the application SSD deploying operating system.

[0110] Figure 3 is an operating system fault self-sensing and self-switching diagram of the application.

[0111] Figure 4 is an operating system self-repairing diagram of the application. DETAILED DESCRIPTION

[0112] In order for those skilled in the art to understand the application scheme, the technical solutions in the embodiments of the application will be described clearly and completely below in conjunction with the drawings in the embodiments of the application. Obviously, the described embodiments are part of the embodiments of the application, rather than all the embodiments. Based on the embodiments in the application, other embodiments obtained by those skilled in the art without creative labor should be within the scope of the application.

[0113] The application will be described in detail below in conjunction with the drawings:

[0114] Embodiment 1:

[0115] Referring to the drawings, Figure 1 the embodiment provides a satellite computer operating system fault-tolerant method, comprising:

[0116] Step 1, creating a main operating system partition, a standby operating system partition and a boot partition in a solid state storage device, the main operating system partition and the standby operating system partition are installed with the same version of general operating system, and the standby operating system partition stores a compressed image file containing complete data of the main operating system partition;

[0117] The main operating system partition and the standby operating system partition in step 1 adopt ext4 file system format, the boot partition adopts FAT32 file system format, and the capacity of the main operating system partition accounts for 30%-40% of the total capacity of the solid state storage device;

[0118] Substep 1.1, calculating the main operating system partition capacity according to the total capacity of the solid state storage device, calculating the main operating system partition capacity:

[0119] S main = a · S total ,

[0120] wherein S main is the main operating system partition capacity, S total is the total capacity of the solid state storage device, and a is a preset proportion coefficient;

[0121] Substep 1.2, creating the main operating system partition and the backup operating system partition using the parted tool with the capacity value calculated in substep 1.1,

[0122] The main operating system partition has a starting offset of 1 MiB and a termination offset of S main ,

[0123] The backup operating system partition has a starting offset of S main + 1 MiB and a capacity equal to S main ,

[0124] The boot partition is created at the end of the solid state storage device and has a capacity of 512 MiB:

[0125]

[0126] wherein MiB is a binary megabyte;

[0127] Substep 1.3, performing bit-level replication on the main operating system partition to generate an original image file, using the LZ4 algorithm for compression with a block size of 4 MB and a compression level of 9, generating a compressed image file stored in the / backup directory of the backup operating system partition, calculating the SHA-256 hash value of the compressed image file and storing it as a verification file, and generating the compressed image file of the main operating system partition:

[0128]

[0129] wherein B i is the i-th 4 MB data block, LBA i is the logical block address, || is data splicing, H img is the image file hash value, is the exclusive or operator, n is the total number of data blocks, and SHA256(·) is the 256-bit version of the secure hash algorithm;

[0130] Step 2, deploying customized boot management software in the boot partition, and configuring the startup flag file storage path and the maximum retry number threshold of the boot management software;

[0131] Sub-step 2.1, based on the GRUB2.06 source code, compile the boot management software, including ext4 file system support module, GPT partition identification module and chain loading module, and the module set M contains at least fs ext4 , part GPT , chainloader three groups of essential modules.

[0132] M={m1,m2,...,m i},m i ∈{fs ext4 ,part GPT ,chainloader},

[0133] Wherein, M is the kernel module set required when compiling the boot management software, fs ext4 is the kernel module of the boot management software, part GPT is the partition management module of the boot management software, and chainloader is the chain loader module.

[0134] m i is a functional module, which at least contains fs ext4 , part GPT , chainloader three groups of essential modules.

[0135] Sub-step 2.2, set the startup flag file storage path to / boot / start flag in the grub.cfg configuration file of the boot partition, and calculate the maximum retry threshold N retry :

[0136]

[0137] Wherein, L PE is the number of program / erase cycles of the solid state storage device, and N retry is the maximum retry threshold.

[0138] Sub-step 2.3, execute the configuration verification script, check whether the startup flag file storage path exists and has write permission, verify whether the maximum retry threshold is an integer between 3 and 5, and trigger a configuration error alarm if any condition is not met:

[0139]

[0140] Wherein, p is the path variable, P flag is the complete storage path of the startup flag file, and dir exist (p) is the path existence verification function.

[0141]

[0142] When dir exist (p) is 1, it indicates that the path p exists and has write permission;

[0143] When dir exist (p) is 0, it indicates that the path p does not exist or is not writable;

[0144] Step 3, when the satellite computer is powered on, the boot management software creates a boot flag file in the startup flag file storage path and loads the main operating system partition;

[0145] Substep 3.1, check whether the boot partition mounting path D boot exists and the remaining space is not less than 1MB, if the verification fails, trigger the path repair process:

[0146] V path =dir exist (D boot )∧free space (D boot )≥S min ,

[0147] where V path is the path validity verification function, dir exist is the directory existence detection function, free space is the storage space detection function, D boot is the boot partition mounting path, and S min is the minimum reserved space;

[0148] Substep 3.2, create an encrypted boot flag file, use AES-GCM algorithm to encrypt and generate a boot flag file F flag , the encrypted content contains the current UTC timestamp and an arbitrary number, and the encryption key K sec is generated by the TPM module of the satellite computer:

[0149] F flag =AES Encrypt (T boot ||H nonce ,K sec ),

[0150] where F flag is the encrypted boot flag file, AES Encrypt (·) is the encryption function, T boot is the boot timestamp, H nonce is a 256 arbitrary number, and K sec is the session key generated by the hardware security module;

[0151] Sub-step 3.3, load the main operating system partition and verify integrity, call grub load Function to load the main operating system partition P main , perform kernel file SHA-256 check and ext4 file system mounting verification, return error code if any verification fails:

[0152]

[0153] Where grub load (·) is the partition loading function, P main is the main operating system partition identifier, sha256 check (·) is the hash check function, ext4 mount is the file system mounting operation, boot is the boot partition technical parameter, and vmlinuz is the kernel file specification.

[0154] Step 4, delete the boot flag file when the main operating system partition starts successfully, and keep the boot flag file and trigger the satellite computer restart when the main operating system partition fails to start;

[0155] The determination conditions for the failure of the main operating system partition in step 4 include at least one of the following: kernel file hash check mismatch, root file system mounting timeout, and system service initialization failure;

[0156] Sub-step 4.1, implement multi-dimensional startup monitoring, monitor the mounting time and system service status of the main operating system partition, and the mounting time T mount is started by calling the ext4 mount function, and the service status detection covers sshd, syslogd, and crond services:

[0157]

[0158] Where T mount is the mounting time, P main is the main operating system partition identifier, ext4 mount is the file system mounting operation, S init is the system service initialization failure counter, s i is the running state of the i-th service, δ is the service state judgment function, δ(s i ) is the quantitative evaluation result of the i-th service state, and m is the total number of key system services monitored.

[0159] Sub-step 4.2, perform hierarchical fault diagnosis, when the kernel file hash value H kernel is inconsistent with the pre-stored reference value H golden , or the root file system mounting time exceeds T maxor the number of failed key service initializations S init When ≥ 3, it is determined that the startup fails:

[0160]

[0161] Wherein, F is a startup failure determination flag, H kernel is the SHA-256 hash value of the current kernel file, H golden is the pre-stored kernel file reference hash value, T max is the root file system mounting timeout threshold;

[0162] Sub-step 4.3, trigger the state response mechanism, delete the startup flag file F flag when the startup is successful, and record the normal state, keep F flag when the startup fails, and trigger the on-board computer hardware reset:

[0163]

[0164] Wherein, R(F) is a state response function, delete(F flag ) is an operation instruction for deleting the startup flag file, log status (OK) is a startup success record written to the system log, keep(F flag ) is a control instruction for keeping the startup flag file, and reboot(·) is a hardware reset trigger function;

[0165] Step 5, the boot management software detects the number of times the startup flag file exists during the restart process, and modifies the partition loading parameter to point to the standby operating system partition when the number of times reaches the maximum retry threshold;

[0166] Sub-step 5.1, decrypt and verify the startup flag file, use the key K sec stored in the hardware security module to decrypt the startup flag file F flag , verify that the deviation of the timestamp T boot from the current time T now does not exceed 5 minutes:

[0167]

[0168] Wherein, D flag is the decrypted startup flag file content, V ts is the timestamp verification result, AES Decrypt (·) is a decryption function based on the AEC-GCM algorithm, verify timestamp (·) is a timestamp verification function, T now is the current time, and ΔT max is the maximum time deviation;

[0169] Sub-step 5.2, count the number of valid boot flags, traverse all encrypted flag files in the / boot directory, and count the number of valid flag files C retry The effective condition is that the timestamp verification is passed and the file content hash value matches the metadata:

[0170]

[0171] Where C retry is the effective retry count counter, and δ(F i ) is the characteristic function,

[0172] hash match(·) is a hash matching verification function;

[0173] Sub-step 5.3, execute partition switching decision, when C retry ≥ N retry , modify the GRUB environment variable to set the root partition to the backup operating system partition, and update the boot configuration file:

[0174]

[0175] Where N retry is the maximum retry threshold,

[0176] set root=(hd0,gpt2) is the GRUB environment variable setting command, hd0W2 the first block device, gpt2 is the second partition in the GPT partition table,

[0177] update-grub-output= / boot / grub / grub.cfg is the boot configuration update command, and output is the specified configuration file path;

[0178] Step 6, after the backup operating system partition is started, access the compressed image file, which is generated by bit-level copying and compressed using the LZ4 algorithm;

[0179] Step 6, when the compressed image file is generated, use a fixed block size of 4MB for data blocking, and set the compression level to 9 levels. The compressed image file is stored in the / backup directory of the backup operating system partition;

[0180] Step 6, the compressed image file contains metadata verification information, which includes the CRC32 checksum value of the original partition, the LBA address mapping table, and the compressed block index table.

[0181] Sub-step 6.1, perform multi-level integrity verification, verify the CRC32 checksum value V meta of the compressed image file metadata with the pre-stored value C storeConsistent, block-by-block check the SHA-256 hash value V of the data before decompression block :

[0182]

[0183] Wherein, V meta is the metadata check result, CRC32(·) is the cyclic redundancy check algorithm, V block is the data block level check result, B i is the ith original data block, SHA256(·) is the secure hash algorithm, H i is the pre-stored hash reference value, M head is the mirror file header metadata, C store is the pre-stored check value;

[0184] Sub-step 6.2, decompress and reconstruct the original mirror image, according to the compressed block index table, use the LZ4 algorithm to decompress the data by 4MB block size, and reconstruct the original mirror image file D raw :

[0185]

[0186] Wherein, D raw is the reconstructed original mirror image data, LZ4 decompress is the LZ4 decompression operation, C j is the jth compressed block, S j is the corresponding block size;

[0187] Sub-step 6.3, perform address mapping conversion, refer to the LBA address mapping table, write the decompressed data block D k to the corresponding logical block address L k , complete the main partition data reconstruction:

[0188]

[0189] Wherein, write lba is the logical block addressing write operation, k is the logical block index, L k is the logical block address, D k is the corresponding data block;

[0190] Step 7, write the decompressed compressed mirror image file to the main operating system partition, complete the data coverage of the main operating system partition, and perform the satellite computer restart operation;

[0191] Before step 7, perform storage medium health state detection, the detection items include bad block quantity statistics, remaining life percentage calculation, and read / write error rate analysis. If any detection item exceeds the preset threshold, the data coverage operation is aborted;

[0192] After step 7 is completed, send a recovery completion status word to the telemetry system of the on-board computer, the status word containing a recovery timestamp, a write data volume, and a check result;

[0193] Sub-step 7.1, implement storage medium health assessment, calculate storage medium health index H, when H≥0.7, allow data overwrite operation, otherwise trigger alarm and abort:

[0194]

[0195] Where w1, w2, w3 are weight coefficients, H is the storage medium health index, B bad is the number of marked bad blocks, B total is the total number of storage medium blocks, C PE is the current cumulative program / erase cycle number, C max is the maximum allowed program / erase cycle number, E rate is the current read / write error rate, E max is the maximum allowed read / write error rate threshold;

[0196] Sub-step 7.2, perform secure erase and data write, execute secure erase and write decompressed data D main block by block according to the LBA address mapping table, and immediately perform read verification for each 1-bit data block: k

[0197]

[0198] Where secure erase (·) is a secure erase function, P main is the main operating system partition identifier, k is the number of logical blocks, N is the total number of data blocks, swrite block (·) is a data block write function, verify block (·) is a data block verification function, L k is the logical block address, D k is the corresponding data block;

[0199] Sub-step 7.3, generate a restart control signal, count the success rate of writing, when the success rate is ≥99.9%, send a restart instruction, otherwise generate an error report and upload it through the telemetry system:

[0200]

[0201] Where R is the restart control signal, reboot() is the execution of hardware restart, alert() is the generation of error report, success rate is the success rate of writing.

[0202] ​The advantage of step 1 lays a physical foundation for the fault-tolerant method by constructing a primary and backup dual-partition storage layout and pre-installing a compressed image, achieving complete data backup at the operating system level at the cost of minimal storage space redundancy. Compared with full-disk mirroring or triple modular redundancy, this scheme greatly improves the utilization of storage media while ensuring data integrity, and the partitioned structure makes it possible to isolate and recover faults.

[0203] The advantage of step 2 is to move the core logic of fault decision to before the operating system loads by deploying configurable customized boot management software, enabling the system to have the ability of autonomous judgment and process control when the kernel crashes or the file system cannot be mounted. By configuring the startup flag and retry threshold, the fault diagnosis process that originally required human intervention is transformed into a deterministic automated process.

[0204] The advantage of step 3 is to create a startup flag file before loading the primary partition, implementing a simple and reliable state marker or watchdog feeding mechanism. The operation itself provides a clear logical starting point for subsequent fault determination, and the existence of the flag will be an unalterable evidence whether the primary operating system starts successfully or not, providing a key basis for the boot management software to identify faults at the next restart.

[0205] The advantage of step 4 is to establish a feedback loop of deleting the flag if the startup is successful, preserving the flag and restarting if the startup fails, clearly defining the triggering conditions and immediate response actions of the fault. The mechanism entrusts the system self-checking responsibility to the operating system itself, uses multi-dimensional monitoring indicators to ensure the accuracy of fault determination, abstracts the complex system state into simple processing of the flag file, and efficiently transfers the system running state to the boot management software.

[0206] The advantage of step 5 is to introduce a retry count and threshold comparison mechanism to add intelligent decision-making and step-by-step escalation capabilities to the fault-tolerant system. This design can effectively distinguish between occasional transient faults and persistent partition damage, avoid performing complex recovery operations immediately due to a single startup failure, prevent the system from falling into an infinite restart loop, and decisively switch to the backup partition when it is confirmed that the primary partition cannot be self-healed by restarting, ensuring the necessity and timeliness of fault-tolerant actions.

[0207] The advantage of step 6 is to access and verify the compressed image in the backup operating system environment, which is a key security confirmation link before performing system recovery. By performing multi-level integrity verification on the image file itself, it can ensure that the data source used for recovery is complete and undamaged, fundamentally eliminating the risk of using damaged backups to repair the system, and ensuring the certainty and reliability of the recovery operation.

[0208] The advantage of step 7 is to finally execute a safe and complete system recovery operation, forming a complete closed loop. The health assessment of the storage medium is performed before writing data, preventing futile writing of data to a physically damaged medium, and the block-by-block verification during the writing process ensures the accuracy of data recovery, and the state reporting and automatic restart after the completion of the recovery mark the end of the autonomous fault-tolerant process.

[0209] Embodiment 2:

[0210] Referring to the accompanying drawings, Figure 2 This embodiment describes an initialization configuration process of a satellite computer operating system fault-tolerant environment, which is completed during the ground test stage of the satellite computer.

[0211] Firstly, a brand new 128GB solid state storage device is partitioned. The storage device is divided into five logical partitions: boot partition 1, swap partition 2, main operating system partition 3, business data partition 4 and backup operating system partition 5.

[0212] Partition creation and formatting:

[0213] Boot partition 1: Use the parted tool to create a boot partition 1 with a capacity of 512 MiB at the starting position of the solid state storage device, and format it as a FAT32 file system, which is used to install customized boot management software.

[0214] Swap partition 2: Create a swap partition 2 with a capacity of 4 GiB next to the boot partition 1, which is used as the virtual memory swap space of the operating system runtime.

[0215] Main operating system partition 3: Calculate the capacity of the main partition according to the formula S main = α·S total , where the proportionality coefficient α is 0.35, and the total capacity S total is 128GB. The calculation shows that the capacity of the main operating system partition 3 is about 44.8 GiB, which is formatted as an ext4 file system.

[0216] Backup operating system partition 5: Create a backup operating system partition 5 with the same capacity as the main operating system partition 3, which is also formatted as an ext4 file system.

[0217] Business data partition 4: Allocate the remaining storage space to the business data partition 4, which is formatted as an ext4 file system, and is used to store scientific and telemetry data generated by on-orbit tasks.

[0218] Operating system installation and image making:

[0219] Install the same version of Linux general operating system in the main operating system partition 3 and the backup operating system partition 5.

[0220] After the system is installed and configured, a bit-level replication operation is performed on the primary operating system partition 3 to generate an original data mirror.

[0221] An LZ4 compression algorithm is called to compress the original data mirror into a compressed mirror file in a fixed block size of 4MB and a compression level of 9. The compressed mirror file contains metadata verification information, which includes a CRC32 verification value of the original partition, an LBA address mapping table, and a compressed block index table.

[0222] The generated compressed mirror file is stored in the / backup directory of the standby operating system partition 5, and a SHA-256 hash value is stored as a verification file, completing the deployment.

[0223] Embodiment 3:

[0224] This embodiment describes the entire process of autonomous perception, switching, and repair after the operating system fails during the on-orbit operation of the satellite computer.

[0225] The first part refers to the attached Figure 3 This process is automatically executed by the customized GRUB boot management software deployed in the boot partition 1.

[0226] 1. Start monitoring and fault determination: When the satellite computer is powered on, the boot management software loads the primary operating system partition 3, and creates an encrypted startup flag file in the boot partition 1. The operating system kernel startup script is modified to increase monitoring of the startup process. When one of the three conditions of kernel file hash verification mismatch, root file system mounting timeout, or key system service initialization failure occurs, the operating system determines that the startup fails.

[0227] If the startup is successful, the operating system will execute a delete instruction to remove the startup flag;

[0228] If the startup fails, the startup flag is retained and a hardware watchdog is triggered immediately to cause the satellite computer to restart.

[0229] 2. Abnormal state recognition: After each restart, the GRUB software first checks whether the startup flag file exists in the startup flag file storage path.

[0230] If the file exists, it indicates that the last attempt to start the main operating system ended in failure, and the GRUB counts this as a startup anomaly.

[0231] 3. Retry threshold determination: The GRUB software maintains a retry counter internally, which is associated with the number of times the startup flag exists. During continuous restarts, the GRUB software accumulates the number of startup anomalies.

[0232] When the cumulative number of times reaches the preset maximum retry threshold of 3 times, it indicates that the primary operating system partition 3 has a serious fault and cannot be recovered by simple restart.

[0233] 4. Autonomous switching of the backup system: when the number of retries reaches the threshold, the GRUB software modifies the partition loading parameters in memory, dynamically points the boot target from the primary operating system partition 3 to the backup operating system partition 5, and then loads the backup operating system kernel, thereby completing autonomous switching.

[0234] The second part, with reference to the attached Figure 4 The process is automatically executed after the backup operating system is successfully started.

[0235] 1. Mirror recovery preparation: after the backup operating system is started, the recovery service in the system automatically runs. The service first performs health state detection on the solid state storage device, evaluates the number of bad blocks, the remaining life percentage, and the read / write error rate. If all detection items do not exceed the preset threshold, the recovery operation is continued.

[0236] The service accesses the compressed image file stored in the backup directory of the partition, and uses the CRC32 check value in the metadata for integrity verification.

[0237] 2. Partition reset and data recovery: after verification, the recovery service performs a secure erase operation on the primary operating system partition 3. Then, the service uses the LBA address mapping table and the compressed block index table in the compressed image file to decompress the data blocks one by one using the LZ4 algorithm, and accurately writes the decompressed data to the corresponding logical block address of the primary operating system partition 3 through bit-level copying, thereby completing the reset of the partition data. During the writing process, read-back verification is performed to ensure the accuracy of data writing.

[0238] 3. Repair completion and system restart: after completing the writing and verification of all data blocks, the recovery service sends a recovery completion status word containing the recovery timestamp, the amount of written data, and the verification result to the telemetry system of the satellite computer. Finally, the service executes a restart instruction to trigger the satellite computer to restart. At this time, the GRUP software will again attempt to start from the primary operating system partition 3 according to the default settings. Since the partition data has been completely restored, the primary operating system can be successfully started, and the flag file is normally deleted, thereby completing the system fault repair.

[0239] Although embodiments of the present application have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made therein without departing from the principles and spirit of the application, and the scope of the present application is defined by the appended claims and their equivalents.

Claims

1. A spaceborne computer operating system fault tolerance method, characterized by, Comprising: Step 1, creating a primary operating system partition, a backup operating system partition and a boot partition in a solid state storage device, the primary operating system partition and the backup operating system partition installing the same version of a general operating system, the backup operating system partition storing a compressed image file containing complete data of the primary operating system partition; Step 2, deploying a customized boot management software in the boot partition, and configuring a startup flag file storage path and a maximum retry threshold of the boot management software; Step 3, when the on-board computer is powered on, the boot management software creates a startup flag file in the startup flag file storage path and loads the primary operating system partition; Step 4, when the primary operating system partition starts successfully, the startup flag file is deleted, and when the primary operating system partition fails to start, the startup flag file is retained and the on-board computer is restarted; Step 5, the boot management software detects the number of times the startup flag file exists during the restart process, and when the number of times reaches the maximum retry threshold, the partition loading parameter is modified to point to the backup operating system partition; Step 6, after the standby operating system partition is started, the compressed image file is accessed, the compressed image file is generated by bit-level replication and adopts algorithm compression; Step 7, the backup operating system partition writes the decompressed compressed image file to the primary operating system partition, and after completing the data coverage of the primary operating system partition, performs the on-board computer restart operation.

2. The fault-tolerant method for an on-board computer operating system according to claim 1, wherein, The step 1 main operating system partition and standby operating system partition adopt file system format, boot partition adopts file system format, main operating system partition capacity accounts for total capacity of solid state storage device The determination condition of the primary operating system partition in step 4 includes at least one of the following: kernel file hash check mismatch, root file system mounting timeout, and system service initialization failure.

3. The fault-tolerant method for an on-board computer operating system according to claim 1, wherein, The step 6 compression image file generation uses Fixed block size data block, compression level set to Level, compressed image file stored in the spare operating system partition Directory under; The compressed image file of step 6 contains metadata verification information, which includes the checksums, address mapping table and compressed block index table of the original partition; Before step 7, a storage medium health state detection is performed, and the detection items include bad block quantity statistics, remaining life percentage calculation, and read / write error rate analysis. If any detection item exceeds the preset threshold, the data coverage operation is aborted; After step 7, a recovery completion status word is sent to the telemetry system of the on-board computer, and the status word includes a recovery timestamp, a written data volume and a verification result.

4. The fault-tolerant method for an on-board computer operating system according to claim 1, wherein, In step 1, creating the primary and backup operating system partitions and storing the compressed image file further comprises: Sub-step 1.1, calculating the primary operating system partition capacity according to the total capacity of the solid state storage device, wherein the primary operating system partition capacity is calculated as follows: ， wherein, is a partition capacity of the main operating system, is a total capacity of the solid state storage device, is a preset proportionality coefficient; Sub-step 1.2, using The tool creates the primary and secondary operating system partitions with the capacity values calculated in sub-step 1.1, The main operating system partition starts at offset and ends at offset , The spare operating system partition start offset is and the capacity is equal to , The boot partition is created at the end of the solid state storage device and has a capacity of : ， wherein, is binary megabyte; Sub-step 1.3, performing bit-level replication on the primary operating system partition to generate a raw image file, using the algorithm to compress with a block size and compression level generate a compressed image file to store in the directory of the standby operating system partition, calculate a hash value of the compressed image file to store as a check file, and generate a compressed image file of the primary operating system partition: ， wherein, is the bit data block, is the logical block address, is the data concatenation, is the mirror file hash value, is the exclusive OR operator, is the total number of data blocks, is the secure hash algorithm bit version.

5. The fault-tolerant method for an on-board computer operating system according to claim 1, wherein, In step 2, deploying the customized boot management software further comprises: Sub-step 2.1, based on The source code compiling boot management software comprises The file system support module, The partition identification module and the chain loading module, the module set At least contains 、 、 Three groups of essential modules; ， ， wherein, a set of kernel modules necessary for compiling the boot management software, a kernel module for the boot management software, a partition management module for the boot management software, a chain loader module, As functional modules, at least , , three groups of essential modules; Sub-step 2.2, in the boot partition The startup flag file storage path is set as , the maximum retry number threshold is calculated : ， wherein, the number of program / erase cycles for the solid state storage device, is a maximum number of retries threshold; Sub-step 2.3, execute configuration verification script, check if startup flag file storage path exists and has write permission, verify if maximum retry number threshold is to an integer, trigger configuration error alarm when any condition is not met: ， wherein, is a path variable, is a complete storage path of the launch flag file, is a path existence verification function; ， When the value of is ; When the value of is .

6. The fault-tolerant method for a spaceborne computer operating system according to claim 1, wherein, In step 3, the boot management software creates a startup flag file and loads the primary operating system partition further comprises: Sub-step 3.1, checking the boot partition mounting path whether there is and the remaining space is not less than If the verification fails, triggering the path repair process: ， wherein, is a path validity verification function, is a directory existence detection function, is a storage space detection function, is a boot partition mount path, is a minimum reserved space; Sub-step 3.2, Create encrypted boot flag file, using Algorithm encryption to generate boot flag file Encrypted content contains current Timestamp and arbitrary number, encryption key Generated by the module of the on-board computer: ​ ， wherein, is an encrypted launch flag file, is an encryption function, is a launch timestamp, is an arbitrary number, is a session key generated by the hardware security module; Sub-step 3.3, loading the main operating system partition and verifying integrity, calling the function LoadMainOSPartition , executing kernel files checking and filesystem mounting verification, returning an error code if any verification fails: ， wherein, is a partition loading function, is a main operating system partition identification, is a hash check function, is a file system mounting operation, is a boot partition technology parameter, is a kernel file specification.

7. The fault-tolerant method for a spaceborne computer operating system according to claim 1, wherein, In step 4, the primary operating system startup state processing further comprises: Sub-step 4.1, implement multi-dimension startup monitoring, monitoring the main operating system partition mounting time and system service status, said mounting time Start timing by calling function, service status detection covers , , Three groups of services: ， wherein, is a mount time, is a main operating system partition identification, is a file system mount operation, is a system service initialization failure counter, is a first service running status, is a service status determination function, is a quantized evaluation result of a first service status, is a total number of monitored critical system services; Sub-step 4.2, perform layered failure judgment, when detecting that the kernel file hash value is inconsistent with the pre-stored reference value , or the root file system mounting time exceeds , or the number of critical service initialization failures , it is determined that the startup fails: ， wherein, is a start fault determination flag, is a current kernel file's hash value, is a pre-stored kernel file reference hash value, is a root file system mounting timeout threshold; Sub-step 4.3, trigger state response mechanism, delete the startup flag file when the startup is successful and record normal state, keep when the startup fails and trigger the on-board computer hardware reset: ， wherein, is a state response function, is an operation instruction for deleting the startup flag file, is a control instruction for writing a startup success record to a system log, is a control instruction for retaining the startup flag file, is a hardware reset trigger function.

8. The fault-tolerant method for a spaceborne computer operating system according to claim 1, wherein, In step 5, the boot management software detects the startup flag and switches the partition further comprises: Sub-step 5.1, decrypting the validation boot flag file, using the key stored in the hardware security module Decrypting the boot flag file , validating the time stamp not deviating more than 5 minutes from the current time from the current time ， wherein, is the decrypted boot flag file content, is the timestamp verification result, is the decryption function based on algorithm, is the timestamp verification function, is the current time, is the maximum time deviation; Sub-step 5.2, count the number of valid start flags, traverse Count the number of valid flag files under the directory The valid condition is that the timestamp verification is passed and the file content hash value matches the metadata: ， ， wherein is an effective retry count counter, is a characteristic function, is a hash match verification function; Sub-step 5.3, performing a partition switching decision, when ≥ the environment variable setting the root partition to the standby operating system partition is modified the boot configuration file is updated: ， wherein, is a maximum number of retries threshold, For environment variable setting command, For the first hard disk device, For The first partition in the partition table partition, To direct the configuration update command, To specify the generated configuration file path.

9. The fault-tolerant method for a spaceborne computer operating system according to claim 1, wherein, In step 6, accessing and processing the compressed image file further comprises: Sub-step 6.1, performing multi-level integrity verification, verifying compressed image file metadata check value consistent with a pre-stored value checking the hash value of the data before decompression hash value : ， wherein, is a metadata check value, is a cyclic redundancy check algorithm, is a data block level check result, is a first original data block, is a secure hash algorithm, is a pre-stored hash reference value, is a mirror file header metadata, is a pre-stored check value; Sub-step 6.2, decompressing and reconstructing the original image, according to the compressed block index table, using the algorithm to decompress the data according to the block size, reconstructing the original image file :​ ， wherein, is the original mirror data, is decompression operation, is the first compressed block, is the corresponding block size; Sub-step 6.3, performing address mapping conversion, referring to address mapping table, the decompressed data block is written into the corresponding logical block address , completing the main partition data reconstruction: , wherein, a logical block addressing write operation, a logical block index, a logical block address, a corresponding data block.

10. The fault-tolerant method for a spaceborne computer operating system according to claim 1, wherein, In step 7, performing data coverage and system restart further comprises: Sub-step 7.1: Perform a storage media health assessment and calculate the storage media health index. ,when Data overwrite operations are allowed only when conditions are met; otherwise, an alarm is triggered and the operation is aborted. ， wherein, , , is a weight coefficient, is a storage medium health index, is a number of marked bad blocks, is a total number of blocks of the storage medium, is a current cumulative number of program / erase cycles, is a maximum allowed number of program / erase cycles, is a current read / write error rate, is a maximum allowed read / write error rate threshold; Sub-step 7.2, performing secure erase and data write to the primary operating system partition Performing secure erase, per Address map table write decompressed data block by block Each write Bit data block read verification performed immediately ， wherein, is a secure erase function, is a main operating system partition identification, is a number of logical blocks, is a total number of data blocks, is a data block write function, is a data block verify function, is a logical block address, is a corresponding data block; Sub-step 7.3, generate a restart control signal, count the success rate of writing, when the success rate is greater than a threshold, send a restart instruction, otherwise generate an error report and upload through the telemetry system: ， wherein, is a restart control signal, is to perform a hardware restart, is to generate an error report, is a write success rate.

Images