Spacecraft embedded file system anti-radiation data storage method and system

Abstract

The invention discloses an anti-radiation data storage method and system for an embedded file system of a spacecraft. The method comprises the steps that file system mounting operation is triggered during starting of an operating system; the file system is initialized before mounting, and the initialization comprises initialization of the structure, an MTD layer and a socket layer of the file system; when mounting is executed, a hardware drive is called to search a matched storage device, if a file system is not primarily preformatted, mounting fails, and a preformatting step is entered, that is, the storage device is preformatted to establish first metadata, and a hardware write drive function is called through an MTD layer write function to realize data writing; mounting the file system again after the pre-formatting is completed; after mounting is completed again, second metadata is created through formatting operation, and data writing is achieved through the writing function and the driving function. The method improves the reliability of the file system in the radiation environment.

Description

Technical Field

[0001] The present invention relates to the field of spacecraft embedded systems, and in particular to a spacecraft embedded file system radiation-resistant data storage method and system. Background Art

[0002] Traditional technical solutions mainly rely on two types of technologies, one is single error correction coding, and the other is operating system-level memory protection.

[0003] Single-code error correction technologies typically employ basic error correction algorithms like Hamming codes, performing encoding and decoding directly at the storage driver layer. The primary drawback of these algorithms is their low error correction efficiency, particularly in the presence of multi-bit burst errors in space radiation environments. Furthermore, single-code error correction codes lack deep integration with the file system's read and write processes, increasing latency during encoding and decoding, which in turn impacts storage throughput.

[0004] Operating system-level memory protection technology uses the VxWorks real-time process (RTP) to isolate task memory spaces, mitigating system-level crashes caused by single-event events. However, this mechanism lacks support for tasks requiring high real-time performance and cannot address data errors inherent in the storage media. More seriously, memory isolation cannot address logical errors at the file system level, such as corruption of TFFS (Flash File System) metadata.

[0005] On this basis, similar technical solutions mainly include the following: The TFFS write optimization method based on block operations improves the performance of embedded storage by improving file system write efficiency, such as block operation consolidation, MTD (Memory Technology Device) layer driver adaptation, and Flash management. Although this method optimizes the performance of spacecraft storage systems, it does not provide data fault tolerance for space radiation environments.

[0006] Software fault tolerance mechanisms, such as adding simple checksums (such as CRC) or dynamically loaded module recovery mechanisms (such as the VxWorks dynamic module management system) to the file system layer (e.g., TFFS), can repair faults by restarting the software or reloading the module. However, simple checksums (such as CRC) have limited error correction capabilities and cannot cope with the high bit error rate radiation environment of space. Furthermore, recovery mechanisms that rely on system restarts or module reloads can degrade real-time performance, making them unable to meet the continuous operation requirements of demanding real-time tasks.

[0007] Hardware-hardened design utilizes radiation-hardened memory chips or redundant memory cell architectures, leveraging redundancy at the physical layer to mitigate the impact of single-event upsets. While this approach effectively protects against single-event upsets at the physical layer, it is costly and, due to the size and power consumption of spacecraft, difficult to implement in large-scale applications. Furthermore, this technology only protects against errors at the physical layer and cannot address the cumulative errors that occur during data encoding and decoding at the logical layer. Summary of the Invention In view of this, an embodiment of the present invention provides a method and system for storing radiation-resistant data in a spacecraft embedded file system to solve at least one of the above technical problems.

[0008] To achieve the above objectives, in a first aspect, a method for storing radiation-resistant data in a spacecraft embedded file system is provided, which comprises the following steps: S1: During the operating system startup process, trigger the file system mount operation; S2: before executing the mount operation, initializing the file system, wherein the initialization includes initializing the structure of the file system, initializing the MTD layer, and initializing the socket layer; S3: When executing the mount operation, calling the hardware driver to search and match the storage device, generating a device structure to complete the mounting of the storage device; if the file system has not been pre-formatted, the mount operation fails and the process proceeds to step S4; S4: performing file system pre-formatting on the storage device, wherein the pre-formatting is used to establish first metadata on the storage device to support the file system's access to and management of the storage device; the pre-formatting implements data writing by calling a hardware write driver function through an MTD layer write function; S5: After the pre-formatting is completed, a re-mounting operation is performed on the file system; S6: After the re-mounting operation is completed, second metadata related to the file system is created through a formatting operation; the second metadata is written into the hardware write driver function by the MTD layer write function.

[0009] In a second aspect, a spacecraft embedded file system radiation-resistant data storage system is provided, comprising: The startup trigger module is used to trigger the file system mount operation during the operating system startup process; An initialization module, configured to initialize the file system before the mount operation is performed, wherein the initialization includes file system structure initialization, MTD layer initialization, and socket layer initialization; A mounting module, configured to call a hardware driver to search for and match storage devices when performing the mounting operation, generate a device structure to complete the mounting of the storage device, and trigger a pre-formatting module if the file system has not been pre-formatted for the first time; A pre-formatting module is used to perform file system pre-formatting on the storage device, wherein the pre-formatting is used to establish first metadata on the storage device to support file system access management of the storage device, and the pre-formatting implements data writing by calling a hardware write driver function through an MTD layer write function; The re-mount module is used to re-mount the file system after pre-formatting is completed; The formatting module is used to create second metadata related to the file system through a formatting operation after the re-mounting operation is completed. The second metadata calls the hardware write driver function through the MTD layer write function to realize data writing.

[0010] According to a third aspect, an electronic device is provided, comprising: one or more processors; a storage device for storing one or more programs, When the one or more programs are executed by the one or more processors, the one or more processors implement the spacecraft embedded file system radiation-resistant data storage method as described in the first aspect.

[0011] In a fourth aspect, a computer-readable storage medium is provided, on which a computer program is stored. When the program is executed by a processor, the spacecraft embedded file system radiation-resistant data storage method as described in the first aspect is implemented.

[0012] In a ninth aspect, a computer program product is provided, comprising a computer-readable storage medium on which a computer program is stored, and when the computer program is run, the spacecraft embedded file system radiation-resistant data storage method described in the first aspect is executed.

[0013] The above technical solution has the following beneficial technical effects: This technical solution effectively improves the radiation-resistant reliability of spacecraft embedded file systems through a coordinated control mechanism for pre-formatting and mounting operations. It breaks down the file system initialization process into a two-stage metadata construction process: first, establishing the basic storage architecture (first metadata) on the storage device to ensure the system's controllable access to the storage media; then, after verifying the availability of the storage media, creating the complete file system structure (second metadata). This segmented initialization strategy reduces the risk of formatting failure due to radiation interference. Combined with a direct data write mechanism at the hardware driver level (invoking hardware write functions via the MTD layer), it ensures the atomicity and media compatibility of metadata writes, thereby enhancing the file system's self-recovery capabilities and startup stability in space radiation environments, meeting the stringent requirements of spacecraft for high-reliability storage systems. BRIEF DESCRIPTION OF THE DRAWINGS

[0014] The accompanying drawings are provided for a better understanding of the present invention and are not intended to limit the present invention. Figure 1 This is a flow chart of a method for radiation-resistant data storage in a spacecraft embedded file system according to an embodiment of the present invention; Figure 2 This is a flow chart of the technical solution for initial mounting of a file system after the introduction of RS codec according to an embodiment of the present invention; Figure 3 This is a flowchart of the most necessary and original technical solution for reading and writing files according to an embodiment of the present invention; Figure 4 This is a flow chart of using RS encoding to perform real-time verification when reading and writing files according to an embodiment of the present invention; Figure 5 This is a flowchart of using RS coding to repair a file system that is unusable according to an embodiment of the present invention; Figure 6 This is a functional block diagram of a spacecraft embedded file system radiation-resistant data storage system according to an embodiment of the present invention; Figure 7 is a functional block diagram of a storage medium according to an embodiment of the present invention; Figure 8 Schematic diagram of the structure of a computer system according to an embodiment of the present invention. DETAILED DESCRIPTION

[0015] The following description of exemplary embodiments of the present invention is made in conjunction with the accompanying drawings, in which various details of the embodiments of the present invention are included to facilitate understanding. These details should be considered as merely exemplary. Therefore, it should be appreciated by those skilled in the art that various changes and modifications may be made to the embodiments described herein without departing from the scope and spirit of the present invention. Similarly, for the sake of clarity and conciseness, descriptions of well-known functions and structures are omitted in the following description.

[0016] An embodiment of the present invention integrates RS encoding and decoding at the MTD layer of the TFFS file system to create an end-to-end radiation-resistant solution for spacecraft embedded storage. This solution includes: encoding data blocks using RS encoding technology to generate redundant checksums before writing to NOR Flash; and real-time error checking and correction during reading. If corruption of TFFS metadata or user data is detected, the file system will not open normally. An interrupt-triggered or proactive detection method is used to initiate a repair program, reconstructing the original data using RS symbols, and restoring the file system to its previous state. RS parameters can be dynamically adjusted automatically or manually based on radiation intensity (monitored by sensors or existing measurements) to balance storage overhead and error correction capabilities.

[0017] The method of the embodiment of the present invention mainly relates to automatic error correction of embedded system files during solid storage and reading. The file management system uses the TFFS file system, the storage device is a (NOR) FLASH non-volatile memory, and the RS encoding and decoding technology is used to implement the error correction function.

[0018] like Figure 1 As shown, the most necessary and original technical solution for mounting a file system for the first time includes the following steps: Step S1: The file system generally needs to be mounted during the startup of the operating system, that is, the mounting operation of the file system is triggered or initiated during the startup of the operating system; Step S2: File system initialization is required before mounting. This step mainly completes the initialization of the TFFS file system structure, as well as the MTD layer and socket layer initialization; #ifdefINCLUDE_TFFS tffsDrv(); #endif The lines #ifdef INCLUDE_TFFS, tffsDrv();, and #endif utilize conditional compilation in the C language. During compilation, the preprocessor checks to see if the INCLUDE_TFFS macro is defined. If so, the tffsDrv() line is retained and included in the actual compilation process. If not, it is skipped.

[0019] In step S3, when the TFFS file system is mounted, the hardware driver is called to search for the hardware device and complete the matching, and a device structure is generated at the same time to complete the mounting of the storage device. If the file system has not been pre-formatted for the first time, the automatic mounting during the operating system startup process will always fail. After the mounting fails, the process goes to step D. After the mounting is successful, the process of this method is exited.

[0020] usrTffsConfig(TFFS_DRIVE_NUMBER,TFFS_REMOVABLE, TFFS_MOUNT_POINT); This is a function used to configure and mount the TFFS file system, where TFFS_DRIVE_NUMBER represents the storage device driver number to be mounted (used to uniquely identify the physical device), TFFS_REMOVABLE indicates whether the device is removable (affecting the security check logic when the system is uninstalled), and TFFS_MOUNT_POINT is the mount point path of the file system in the operating system (that is, the directory entry for accessing the file system); this function calls the hardware driver to find and match the target device and generate a device structure to complete the mount. If the device is not pre-formatted, the mount fails and metadata must be established by formatting before the mount operation can be performed.

[0021] In the TFFS file system, the device structure is a data structure generated by the system at mount time (for example, TFFS_DEVICE). It encapsulates the core parameters of the physical storage device (such as sector size, total capacity, and erase block size) and the driver interface (read / write / erase function pointers). It serves as a bridge between the file system and the hardware driver, freeing upper-level operations from having to worry about specific hardware details. This structure is filled in and registered with the system during the mount process. If the device is not pre-formatted, the missing metadata in the structure (such as the file allocation table) will cause the mount to fail. The metadata area must first be initialized through a formatting operation.

[0022] Step S4: Execute TFFS file system pre-formatting. Specifically, pre-formatting is to establish metadata on the storage device to enable the TFFS file system to more efficiently access and manage the Flash storage device; tffsDevFormat(drives,0), ​​where drives is the drive number. When the second bit is 0, it will use the default parameters and control bits to format the underlying Flash device. Pre-formatting metadata creation requires the MTD layer write function to call the hardware write driver function to implement data writing; The MTD layer write function is as follows: FLStatus wedMTDWrite(FLFlashvol, CardAddress address, const void FAR1 *buffer, int length, int overwrite).

[0023] Among them, vol is the Flash volume handle, which identifies the specific Flash device instance; address is the target address to be written, NOR FLASH is the physical address; buffer is the source data pointer, that is, the pointer points to the first address of the data block to be written; length is the length of the source data to be written; overwrite indicates the overwrite mode flag; The hardware write driver function is as follows: int NorFlash_Write(u8 chipnums, u32 offset_addr, u32 len, const char *buf). NorFlash_Write is a low-level driver function used to write data to a NOR Flash storage device. chipnums is the chip number (used in multi-chip cascade scenarios), offset_addr is the starting physical address for writing, len is the length of the data to be written, and buf is a pointer to the source data, which points to the source data buffer. This function is indirectly called through the MTD layer to write low-level data to the target chip. Address alignment and chip erasure are required. This is a key low-level operation for establishing metadata in TFFS pre-formatting.

[0024] Step S5: Mount the TFFS file system again; Step S6: Finally, the file system metadata is created by formatting, including the directory table, file allocation table (FAT), index node (inode), etc., to ensure that the file system can work properly; dosFsVolFormat "tffsName" Among them, tffsName is the specific tffs file system name; The formatting method creates metadata related to the file system and calls the write driver of the MTD layer to write data. The writing principle is the same as the MTD layer writing process in the previous step S4.

[0025] The above-mentioned first metadata is the underlying metadata established in the pre-formatting stage, which includes flash memory physical structure information (such as erase block division, bad block management table, device sector size and capacity parameters), basic driver interface configuration (registering hardware read / write / erase function pointers) and original storage mapping relationship (logical unit and physical block association), which is used to solve the compatibility between flash memory hardware characteristics and file system and provide underlying access support; the difference between it and the second metadata is that the first metadata belongs to physical layer metadata, established in the pre-formatting stage, and its content revolves around hardware structure and driver interface. It is updated infrequently and is the basis of the second metadata, while the second metadata is logical layer metadata created in the formatting stage after re-mounting, which includes file system logical structures and advanced management information such as directory table, FAT, inode, super block, etc., and is used to build a logical management system, support user-level file operations, and is dynamically updated with file operations and relies on the physical structure information of the first metadata.

[0026] like Figure 2 As shown, a further technical solution is a technical solution for the initial mounting of the file system after the introduction of RS codec, which includes the following steps: Step S1: The file system generally needs to be mounted when the operating system is started; Step S2: File system initialization is required before mounting, mainly completing the initialization of the TFFS file system structure, as well as the MTD layer and Socket layer initialization; #ifdefINCLUDE_TFFS tffsDrv(); #endif Step S3: When the file system is mounted, the hardware driver is called to search for the hardware device and complete the matching, and a device structure is generated to complete the device mounting. If the file system has not been pre-formatted for the first time, the automatic mounting during the operating system startup process will always fail. usrTffsConfig(TFFS_DRIVE_NUMBER,TFFS_REMOVABLE, TFFS_MOUNT_POINT).

[0027] Step S4, pre-formatting is to create metadata on the storage device to enable the TFFS file system to more efficiently access and manage the Flash storage device; tffsDevFormat(drives,0), ​​where drives is the drive number. When the second bit is 0, it will use the default parameters and control bits to format the underlying Flash device. Step S41: Call the RS encoding function to encode the data block written into the file system, and write the generated code element block into the corresponding address for storage; The RS encoding function is as follows: void rs_encode_msg(const gf_u8 *msg_in, gf_u32 size_in, const gf_u8 *gen, gf_u32 gen_len, gf_u8 *msg_out, gf_u32 size_out, gf_u8 *g_table, gf_u8 *g_log, gf_u32 sl). rs_encode_msg is a function that implements Reed-Solomon (RS) encoding. Its parameters are as follows: msg_in is a pointer to the original data block to be encoded, which serves as the input for the RS encoding; size_in is the byte length of the input data; gen is the array of coefficients for the RS encoding generator polynomial; gen_len is the length of this array; these two parameters together determine the error correction capability of the encoding; msg_out is the encoded output data block (consisting of the original data and check symbols); size_out is the total output length, with space reserved for check symbols; g_table and g_log are precomputed Galois field multiplication and logarithm tables, respectively, to accelerate finite field operations; and sl is the starting offset for the encoding operation (e.g., the block index for block encoding). This function uses the generator polynomial to expand the original data into blocks of symbols with redundancy check, improving data storage fault tolerance. The encoded results are then written to the storage medium via the hardware driver.

[0028] The generated code elements are stored by calling the corresponding hardware driver function according to the storage medium.

[0029] Pre-formatting metadata creation requires the MTD layer write function to call the hardware write driver function to implement data writing; The MTD layer write function is as follows: FLStatus wedMTDWrite(FLFlashvol, CardAddress address, const void FAR1 *buffer, int length, int overwrite).

[0030] Among them, vol is the Flash volume handle, which identifies the specific Flash device instance; address is the target address to be written, NOR FLASH is the physical address; buffer is the source data pointer, that is, the pointer points to the first address of the data block to be written; length is the length of the source data to be written; overwrite indicates the overwrite mode flag; The hardware write driver function is as follows: int NorFlash_Write(u8 chipnums,u32 offset_addr,u32 len,const char *buf).

[0031] Step S5: Mount the file system again; Step S6: Finally, the file system metadata is created by formatting, including the directory table, file allocation table (FAT), index node (inode), etc., to ensure that the file system can work properly; dosFsVolFormat "tffsName", where tffsName is the specific tffs file system name; Step S61: The working principle of step S61 is the same as that of step S41; The formatting method creates metadata related to the file system and calls the write driver of the MTD layer to write data; the writing principle is the same as the MTD layer writing process in step S4; The code element storage device can be a non-file system non-volatile accessible area of ​​the same FLASH, or a non-file system non-volatile accessible area of ​​a different FLASH.

[0032] like Figure 3 As shown, the process of the most necessary original technical solution for file reading and writing includes the following steps: First, initialize and mount the file system before using it; Step S7, determine whether to write the file, if the file needs to be written, execute step S8; Step S8: When writing a file, first search for the target file. If the target file is found, proceed directly to the next step. If not found, create the file. Step S9: If the Flash supports write protection (which can protect data from being written or modified under certain circumstances), the write protection needs to be removed before writing; Step S10: The TFFS file system adopts a block-by-block writing strategy when writing the target file. The file data block is written by the MTD layer write function calling the hardware write driver function; The MTD layer write function is as follows: FLStatus wedMTDWrite(FLFlashvol, CardAddress address, const void FAR1 *buffer, int length, int overwrite).

[0033] Among them, vol is the Flash volume handle, which identifies the specific Flash device instance; address is the target address to be written, NOR FLASH is the physical address; buffer is the source data pointer, that is, the pointer points to the first address of the data block to be written; length is the length of the source data to be written; overwrite indicates the overwrite mode flag; The hardware write driver function is as follows: int NorFlash_Write(u8 chipnums,u32 offset_addr,u32 len,const char *buf).

[0034] Step S11: After writing is completed, FLASH restores write protection; Step S12: close the target file; Step S13: Determine whether to read the file; if the file needs to be read, execute step S14; Step S14: When reading a file, first search for the target file and obtain the first address of the target file; Step S15: Read data according to the address; specifically, the MTD layer read function calls the hardware read driver function to implement data writing; The MTD layer read function is as follows: FLStatus wedMTDRead(FLFlashvol, CardAddress address, const void FAR1 *buffer, int length, int a).

[0035] Among them, vol is the Flash volume handle, which identifies the specific Flash device instance; address is the target address to be read, NOR FLASH is the physical address; buffer is the source data pointer, that is, the pointer points to the first address of the block where the read data is stored; length is the length of the data to be read; a is temporarily invalid and is only used for occupation; The hardware write driver function is as follows: int NorFlash_Read(u8 chipnums,u32 offset_addr,u32len,char *buf).

[0036] Step S16: combining the file data blocks into a target file; Step S17: Close the target file.

[0037] like Figure 4 As shown, in a further technical solution, using RS encoding for real-time verification when reading and writing files includes the following steps: First, initialize and mount the file system before using it; Step S7, determine whether to write the file, if the file needs to be written, execute step S8; Step S8: When writing a file, first search for the target file. If the target file is found, proceed directly to the next step. If not found, create the file. Step S9: If the Flash supports write protection (which can protect data from being written or modified under certain circumstances), the write protection needs to be removed before writing; Step S10: The TFFS file system adopts a block-by-block writing strategy when writing the target file, and processes the file in blocks; Step S101: Call the RS encoding function to encode the data block written into the file system, and write the generated code element block into the corresponding address for storage; The RS encoding function is as follows: void rs_encode_msg(const gf_u8 *msg_in, gf_u32 size_in, const gf_u8 *gen, gf_u32 gen_len, gf_u8 *msg_out, gf_u32 size_out, gf_u8 *g_table, gf_u8 *g_log, gf_u32 sl).

[0038] The file data block is written by the MTD layer write function calling the hardware write driver function; The MTD layer write function is as follows: FLStatus wedMTDWrite(FLFlashvol, CardAddress address, const void FAR1 *buffer, int length, int overwrite).

[0039] Among them, vol is the Flash volume handle, which identifies the specific Flash device instance; address is the target address to be written, NOR FLASH is the physical address; buffer is the source data pointer, that is, the pointer points to the first address of the data block to be written; length is the length of the source data to be written; overwrite indicates the overwrite mode flag; The hardware write driver function is as follows: int NorFlash_Write(u8 chipnums,u32 offset_addr,u32len,const char *buf).

[0040] Step S11: After writing is completed, FLASH restores write protection; Step S12: close the target file; Step S13: Determine whether to read the file; if the file needs to be read, execute step S14; Step S14: When reading a file, first search for the target file and obtain the first address of the target file; Step S15: Read data according to the address; specifically, the MTD layer read function calls the hardware read driver function to implement data writing; The MTD layer read function is as follows: FLStatus wedMTDRead(FLFlashvol, CardAddress address, const void FAR1 *buffer, int length, int a).

[0041] Among them, vol is the Flash volume handle, which identifies the specific Flash device instance; address is the target address to be read, NOR FLASH is the physical address; buffer is the source data pointer, that is, the pointer points to the first address of the block where the read data is stored; length is the length of the data to be read; a is temporarily invalid and is only used for occupation; The hardware write driver function is as follows: int NorFlash_Read(u8 chipnums,u32 offset_addr,u32len,char *buf).

[0042] Step S151: Call the RS decoding function to decode the read file system data block, and save the corresponding decoded code element block at the corresponding address; The RS decoding function is as follows: void rs_decode_msg(gf_u8 *msg_in, gf_u8 *msg_out, gf_u32 size_m, gf_u8 *g_table, gf_u8 *g_log, gf_u32 bl, gf_u32 cl, gf_u32 sl).

[0043] Step S16: combining the file data blocks into a target file; Step S17: Close the target file.

[0044] like Figure 5 As shown, in a further technical solution, using RS coding to repair a file system when it is unusable includes the following steps: Step A: The operating system starts up and executes the startup program to prepare the operating environment for file system operations.

[0045] Step B: Initializing and mounting the TFFS file system when it is not the first time the system is started. Initialize the TFFS file system and mount it to the operating system directory tree.

[0046] Step C: Determine whether the file system is damaged. Specifically, after the file system is mounted, determine whether the TFFS file system is damaged. If damage is detected, go to step D; if not, go to step G.

[0047] Step D: Start the file system repair process. When the file system is damaged, the repair process is triggered and the RS (Reed-Solomon) code error correction mechanism is started.

[0048] Step E: Perform full file system error correction based on all RS decoding symbols. Specifically, call the RS decoding function and perform symbol-level error correction on all data blocks in the file system based on all stored RS decoding symbols to restore data integrity.

[0049] Step F: Determine whether to restart the operating system. After the repair is complete, determine whether the operating system needs to be restarted based on the system status. If a restart is required, return to step A (restarting the operating system); if not, go to step G.

[0050] Step G: Determine whether to read or write files. After the file system is not damaged or has been repaired, check whether there is a read or write operation request: if there is a read or write request, go to step H; if not, go to step I.

[0051] Step H: Create or open a file. When writing to a file, if the target file does not exist, a new file is created. When reading from a file, the target file is first opened and the read / write operation is performed.

[0052] Step I: File Closing: After the file operation is completed, the opened target file is closed and resources are released, and the file system operation process is finally exited. In an alternative embodiment, the following alternative implementations may be employed: A shortened RS code is used at the MTD layer to correct high-frequency single-bit errors, while an LDPC code is added at the file system layer to cope with sudden multi-bit errors, forming a hybrid error correction architecture.

[0053] Implementing the RS codec in FPGA and utilizing a parallel pipeline structure can significantly improve the codec throughput compared to pure embedded software solutions.

[0054] To improve the utilization rate of codecs, specific FPGA drivers can be integrated into the MTD layer through VxWorks BSP customization.

[0055] The advantages of the above technical solutions of the embodiments of the present invention are: For the first time, the RS codec is embedded in the MTD driver layer, achieving coordinated fault tolerance between the storage medium (NOR Flash) and the file system (TFFS), breaking through the limitations of traditional single-layer protection (optimized by comparing circuit-level reinforcement with pure file system); The file repair process can be initiated through interrupt triggering or active detection, reducing manual intervention, lowering latency, improving file reliability, and lowering the risk of onboard computer downtime. Encoding parameters can be adjusted dynamically, automatically or manually, to accommodate differences in radiation intensity in different orbits (e.g. LEO vs GEO).

[0056] like Figure 6 As shown, a spacecraft embedded file system radiation-resistant data storage system includes: The startup trigger module is used to trigger the file system mount operation during the operating system startup process; An initialization module, configured to initialize the file system before the mount operation is performed, wherein the initialization includes file system structure initialization, MTD layer initialization, and socket layer initialization; A mounting module, configured to call a hardware driver to search for and match storage devices when performing the mounting operation, generate a device structure to complete the mounting of the storage device, and trigger a pre-formatting module if the file system has not been pre-formatted for the first time; A pre-formatting module is used to perform file system pre-formatting on the storage device, wherein the pre-formatting is used to establish first metadata on the storage device to support file system access management of the storage device, and the pre-formatting implements data writing by calling a hardware write driver function through an MTD layer write function; The re-mount module is used to re-mount the file system after pre-formatting is completed; The formatting module is used to create second metadata related to the file system through a formatting operation after the re-mount operation is completed. The second metadata includes a directory table, a file allocation table and an index node. The second metadata calls the hardware write driver function through the MTD layer write function to realize data writing.

[0057] In some embodiments, the MTD layer write function is implemented by the wedMTDWrite driver module, and the parameters of the wedMTDWrite include the Flash volume handle, the target address, the source data pointer, the data length and the overwrite mode flag; The hardware write driver function is implemented by the NOR Flash write driver module NorFlash_Write. The parameters of NorFlash_Write include chip number, offset address, data length and data buffer; The formatting operation is implemented by the dosFsVolFormat function module, and the parameter of the dosFsVolFormat function is the file system name; The initialization module triggers the tffsDrv function module to complete the file system initialization through the conditional compilation control module #ifdef INCLUDE_TFFS; The mount module configures the drive number, removable attribute, and mount point through the usrTffsConfig configuration module to perform the mount operation.

[0058] In some embodiments, the pre-formatting module has a built-in pre-formatting encoding submodule, which calls the RS encoding module to encode the data block corresponding to the first metadata to generate a symbol block before calling the MTD layer write function. The symbol block and the data block corresponding to the first metadata are written to the storage device together by calling the hardware write driver function through the MTD layer write function; The formatting module has a built-in formatting coding sub-module, which calls the RS coding module to encode the data block corresponding to the second metadata to generate a codeword block before calling the MTD layer write function. The codeword block and the data block corresponding to the second metadata are written to the storage device together through the MTD layer write function calling the hardware write driver function.

[0059] In some embodiments, the RS encoding module is implemented by the rs_encode_msg function unit, and the parameters of the rs_encode_msg function unit include input data pointer, input data length, generating polynomial pointer, generating polynomial length, output data pointer, output data length, logarithmic table pointer, antilogarithmic table pointer and symbol length.

[0060] In some embodiments, after the module is mounted again, a file writing process module is added, including: The write judgment submodule is used to determine whether to write a file. If writing is required, it triggers the file search and creation submodule; The file search and creation submodule is used to search for the target file. If the target file is found, the write protection processing submodule is triggered. If the target file is not found, the write protection processing submodule is triggered after the target file is created; A write protection processing submodule, configured to release the write protection of the storage device before writing if the storage device supports the write protection function; The block writing submodule is used to adopt a block writing strategy for the target file, and calls the hardware write driver function through the MTD layer write function to write the data blocks of the target file into the storage device; The write protection recovery submodule is used to restore the write protection of the storage device after writing is completed; Write the close submodule to close the target file.

[0061] In some embodiments, after the module is re-mounted, a file reading process module is added, which includes: The read judgment submodule is used to determine whether to read the file. If reading is required, the file address search submodule is triggered; The file address search submodule is used to search for the target file and obtain the first address of the target file; The data block reading submodule is used to read the file data block according to the first address by calling the hardware read driver function through the MTD layer read function; The file combination submodule is used to combine file data blocks into a target file; Read the close submodule to close the target file.

[0062] In some embodiments, the MTD layer read function is implemented by the wedMTDRead module, and the parameters of the wedMTDRead module include the Flash volume handle, the read target address, the data storage pointer, the data length, and the invalid flag; The hardware read driver function is implemented by the NorFlash_Read module, and the parameters of the NorFlash_Read module include chip number, offset address, data length, and data buffer.

[0063] In some embodiments, the block writing submodule has a built-in write encoding submodule, which calls the RS encoding module to encode the data block to generate a symbol block before calling the MTD layer write function after the block processing, and the symbol block is written to the storage device together with the data block by calling the hardware write driver function through the MTD layer write function; The data block reading submodule has a built-in reading and decoding submodule. After reading the file data block and before the file is assembled, the RS decoding function is called to decode the read data block. The RS decoding function is rs_decode_msg, and its parameters include input data pointer, output data pointer, data length, logarithm table pointer, antilogarithm table pointer, data block length, code element length and symbol length. The data integrity is verified based on the corresponding stored code element block.

[0064] In some embodiments, a file system repair process module is added before the write judgment submodule or the read judgment submodule, including: Write process pre-repair submodule, which includes: A write repair detection unit is used to detect whether the file system can be used normally, and if not, to start a program to repair the file system; Write an error correction unit to call the RS decoding function to perform error correction on the symbol blocks corresponding to all data blocks in the file system; A write recovery unit, which is used to trigger the write judgment submodule and subsequent file writing process after error correction is completed; Read the pre-repair submodule of the process, which includes: A read repair detection unit is used to detect whether the file system can be used normally, and if not, to start a program to repair the file system; The read error correction unit is used to call the RS decoding function to correct the code blocks corresponding to all data blocks of the file system; The read recovery unit is used to trigger the read judgment submodule and subsequent file reading process after error correction is completed.

[0065] Those skilled in the art can clearly understand that, for the convenience and brevity of description, only the division of the above-mentioned functional units and modules is used as an example for illustration. In actual applications, the above-mentioned functions can be distributed and completed by different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiment can be integrated into one processing unit, or each unit can exist physically alone, or two or more units can be integrated into one unit. The above-mentioned integrated unit can be implemented in the form of hardware or in the form of software functional units. In addition, the specific names of the functional units and modules are only for the convenience of distinguishing each other, and are not used to limit the scope of protection of this application. The specific working process of the units and modules in the above-mentioned system can refer to the corresponding process in the aforementioned method embodiment, and will not be repeated here.

[0066] like Figure 7 As shown, an embodiment of the present invention further provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements any of the above-mentioned radiation-resistant data storage methods for a spacecraft embedded file system.

[0067] If the integrated modules / units are implemented as software functional units and sold or used as standalone products, they can be stored in a computer-readable storage medium. Based on this understanding, the present invention can also implement all or part of the process steps in the above-mentioned method embodiments by using a computer program to instruct the relevant hardware. The computer program can be stored in a computer-readable storage medium. When executed by a processor, the computer program can implement the steps of each of the above-mentioned method embodiments. The computer program includes computer program code, which can be in source code form, object code form, executable file, or some intermediate form. The computer-readable medium can include: any entity or device capable of carrying the computer program code, recording medium, USB flash drive, mobile hard drive, magnetic disk, optical disk, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signal, telecommunication signal, and software distribution medium. Of course, there are other types of readable storage media, such as quantum memory and graphene memory. It should be noted that the content contained in the computer-readable medium can be appropriately increased or decreased according to the requirements of legislation and patent practices in the jurisdiction. For example, in some jurisdictions, according to legislation and patent practices, computer-readable media do not include electrical carrier signals and telecommunication signals.

[0068] The present invention also provides an electronic device. The electronic device in an embodiment of the present invention includes: one or more processors; and a storage device configured to store one or more programs. When the one or more programs are executed by the one or more processors, the one or more processors implement the radiation-resistant data storage method for a spacecraft embedded file system provided by the present invention.

[0069] Reference below Figure 8 , which shows a schematic structural diagram of a computer system 800 of an electronic device suitable for implementing an embodiment of the present invention. Figure 8 The electronic device shown is only an example and should not limit the functions and scope of use of the embodiments of the present invention.

[0070] like Figure 8As shown, computer system 800 includes a central processing unit (CPU) 801, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 802 or a program loaded from a storage unit 808 into a random access memory (RAM) 803. Various programs and data required for the operation of computer system 800 are also stored in RAM 803. CPU 801, ROM 802, and RAM 803 are connected to each other via a bus 804. An input / output (I / O) interface 805 is also connected to bus 804.

[0071] The following components are connected to the I / O interface 805: an input section 806 including a keyboard, mouse, and the like; an output section 807 including devices such as a cathode ray tube (CRT), a liquid crystal display (LCD), and speakers; a storage section 808 including a hard disk; and a communication section 809 including a network interface card such as a LAN card or a modem. The communication section 809 performs communication processing via a network such as the Internet. A drive 810 is also connected to the I / O interface 805 as needed. Removable media 811, such as a magnetic disk, an optical disk, a magneto-optical disk, or a semiconductor memory, is installed in the drive 810 as needed, so that computer programs read from the removable media can be installed in the storage section 808 as needed.

[0072] In particular, according to embodiments disclosed herein, the processes described in the main step diagrams above can be implemented as computer software programs. For example, embodiments of the present invention include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for executing the methods shown in the main step diagrams. In the above embodiments, the computer program can be downloaded and installed from a network via the communication section 809 and / or installed from removable media 811. When the computer program is executed by the central processing unit 801, the above-described functions defined in the system of the present invention are performed.

[0073] It should be noted that the computer-readable medium described in the present invention may be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. Computer-readable storage media may include, for example, but not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or components, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to, an electrical connection having one or more conductors, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination thereof. In the present invention, a computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, device, or component. In the present invention, a computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such a propagated data signal may take a variety of forms, including, but not limited to, electromagnetic signals, optical signals, or any suitable combination thereof. A computer-readable signal medium may also be any computer-readable medium other than a computer-readable storage medium that can transmit, propagate, or transport a program for use by or in conjunction with an instruction execution system, apparatus, or device. Program code embodied on a computer-readable medium may be transmitted using any suitable medium, including but not limited to wireless, wireline, optical cable, RF, or any suitable combination thereof.

[0074] The flowcharts and block diagrams in the accompanying drawings illustrate the possible implementation architecture, functions and operations of the systems, methods and computer program products according to various embodiments of the present invention. In this regard, each box in the flowchart or block diagram can represent a module, program segment, or a part of code, and the above-mentioned module, program segment, or a part of code contains one or more executable instructions for implementing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in an order different from that marked in the accompanying drawings. For example, two boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram or flowchart, and the combination of boxes in the block diagram or flowchart, can be implemented with a dedicated hardware-based system that performs the specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0075] The above specific embodiments do not limit the scope of protection of the present invention. Those skilled in the art will appreciate that various modifications, combinations, sub-combinations, and substitutions may occur depending on design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of the present invention are intended to be included within the scope of protection of the present invention.

Claims

1. A method for storing radiation-resistant data in a spacecraft embedded file system, characterized in that: The following steps are involved: S1: During the operating system startup process, trigger the file system mount operation; S2: before executing the mount operation, initializing the file system, wherein the initialization includes initializing the structure of the file system, initializing the MTD layer, and initializing the socket layer; S3: When executing the mount operation, calling the hardware driver to search and match the storage device, generating a device structure to complete the mounting of the storage device; If the file system has not been pre-formatted for the first time, the mounting operation fails and the process goes to step S4; S4: performing file system pre-formatting on the storage device, wherein the pre-formatting is used to establish first metadata on the storage device to support the file system's access to and management of the storage device; the pre-formatting implements data writing by calling a hardware write driver function through an MTD layer write function; S5: After the pre-formatting is completed, a re-mounting operation is performed on the file system; S6: After the re-mounting operation is completed, second metadata related to the file system is created through a formatting operation; the second metadata is written into the hardware write driver function by the MTD layer write function.

2. The method for storing radiation-resistant data in a spacecraft embedded file system according to claim 1, characterized in that: In step S4, the MTD layer write function is wedMTDWrite, and the parameters of wedMTDWrite include Flash volume handle, target address, source data pointer, data length and overwrite mode flag; The hardware write driver function is a NOR Flash write driver function NorFlash_Write, and the parameters of NorFlash_Write include chip number, offset address, data length and data buffer; In step S6, the formatting operation is implemented by the dosFsVolFormat function, and the parameter of the dosFsVolFormat function is the file system name; In step S2, the initialization of the file system is controlled by the conditional compilation instruction #ifdef INCLUDE_, and the Drv function is called under the action of the conditional compilation instruction to complete the initialization; In step S3, the drive number, movable attribute and mount point are configured through the usrConfig function to perform the mount operation.

3. The spacecraft embedded file system radiation-resistant data storage method according to claim 1, characterized in that: In step S4, before the MTD layer write function calls the hardware write driver function, the following steps are also included: Step S41: calling the RS encoding function to encode the data block corresponding to the pre-formatted first metadata to generate a symbol block; the symbol block and the data block corresponding to the first metadata are written into the storage device by calling the hardware write driver function through the MTD layer write function; In step S6, before the MTD layer write function calls the hardware write driver function, the step further includes: Step S61: calling the RS encoding function to encode the data block corresponding to the second metadata to generate a symbol block; the symbol block and the data block corresponding to the second metadata are written into the storage device by calling the hardware write driver function through the MTD layer write function.

4. The method for storing radiation-resistant data in a spacecraft embedded file system according to claim 3, characterized in that: The RS encoding function is rs_encode_msg, and its parameters include: input data pointer, input data length, generating polynomial pointer, generating polynomial length, output data pointer, output data length, logarithmic table pointer, antilogarithmic table pointer and symbol length.

5. The method for storing radiation-resistant data in a spacecraft embedded file system according to claim 1, wherein: After the file system completes the re-mount operation, a file writing process is further included, and the file writing process includes: Step S7: Determine whether to write a file; if the file needs to be written, execute step S8; Step S8: Search for the target file; if the target file is found, execute step S9; if not found, create the target file and execute step S9; Step S9: If the storage device supports a write protection function, remove the write protection of the storage device before writing; Step S10: adopting a block writing strategy for the target file, calling a hardware write driver function through the MTD layer write function, and writing the data blocks of the target file into the storage device; Step S11: After writing is completed, restoring the write protection of the storage device; Step S12: Close the target file.

6. The method for storing radiation-resistant data in a spacecraft embedded file system according to claim 1 or 2, characterized in that: After the file system completes the re-mounting operation, a file reading process is further included, and the file reading process includes: Step S13: Determine whether to read the file; if the file needs to be read, execute step S14; Step S14: Search for the target file and obtain the first address of the target file; Step S15: calling the hardware read driver function through the MTD layer read function to read the file data block according to the first address; Step S16: combining the file data blocks into a target file; Step S17: Close the target file.

7. The method for storing radiation-resistant data in a spacecraft embedded file system according to claim 6, characterized in that: The MTD layer read function is wedMTDRead, and its parameters include Flash volume handle, read target address, data storage pointer, data length, and invalid flag; The hardware read driver function is NorFlash_Read, and its parameters include chip number, offset address, data length, and data buffer.

8. The method for storing radiation-resistant data in a spacecraft embedded file system according to claim 5, characterized in that: After adopting the block writing strategy for the target file in step S10 and before calling the hardware write driver function through the MTD layer write function, the method further includes: Step S101: calling the RS encoding function to encode the data block after block processing to generate a symbol block; the symbol block and the data block are written into the storage device by calling the hardware write driver function through the MTD layer write function; After calling the hardware read driver function through the MTD layer read function to read the file data blocks in step S15 and before combining the file data blocks into the target file, the method further includes: Step S151: Call the RS decoding function to decode the read data block and verify the data integrity based on the corresponding stored codeword block; the RS decoding function is rs_decode_msg, and its parameters include: input data pointer, output data pointer, data length, logarithm table pointer, antilogarithm table pointer, data block length, codeword length and symbol length.

9. The method for storing radiation-resistant data in a spacecraft embedded file system according to claim 8, characterized in that: Before the step S7 of determining whether to write a file is executed, or before the step S13 of determining whether to read a file is executed, a file system repair process is also included, and the file system repair process includes a pre-repair sub-process of the write process before step S7 and a pre-repair sub-process of the read process before step S13; The pre-repair sub-process of the write process includes: Detecting whether the file system is usable; if not, starting a program to repair the file system; Calling the RS decoding function to perform error correction on the symbol blocks corresponding to all data blocks of the file system; After the error correction is completed, continue to execute step S7 and the subsequent file writing process; The pre-repair sub-process of the reading process includes: Detecting whether the file system is usable; if not, starting a program to repair the file system; Calling the RS decoding function to perform error correction on the symbol blocks corresponding to all data blocks of the file system; After the error correction is completed, step S13 and the subsequent file reading process are continued.

10. A spacecraft embedded file system radiation-resistant data storage system, characterized in that: include: The startup trigger module is used to trigger the file system mount operation during the operating system startup process; An initialization module, configured to initialize the file system before the mount operation is performed, wherein the initialization includes file system structure initialization, MTD layer initialization, and socket layer initialization; A mounting module, configured to call a hardware driver to search for and match storage devices when performing the mounting operation, generate a device structure to complete the mounting of the storage device, and trigger a pre-formatting module if the file system has not been pre-formatted for the first time; A pre-formatting module is used to perform file system pre-formatting on the storage device, wherein the pre-formatting is used to establish first metadata on the storage device to support file system access management of the storage device, and the pre-formatting implements data writing by calling a hardware write driver function through an MTD layer write function; The re-mount module is used to re-mount the file system after pre-formatting is completed; The formatting module is used to create second metadata related to the file system through a formatting operation after the re-mounting operation is completed. The second metadata calls the hardware write driver function through the MTD layer write function to realize data writing.

Images