Satellite-borne software high-reliability rapid reconfiguration method

Abstract

The application relates to a kind of high reliability fast reconfiguration methods of spaceborne software.The method comprises: using SmartFusion2 chip, FLASH module and the like to construct spaceborne processor, after sending instruction to space vehicle, spaceborne processor reads the executable file of software configuration item in FLASH chip and verifies return value, thereby confirming program version and data correctness, and generating reconfiguration difference data packet.Determine the size of data block, segment and compress relevant files, select blocks according to compression rate to form to-be-injected files and generate decompression information.Again through the decompression information and to-be-injected files of space-ground link are injected to the spacecraft, and the spaceborne processor is decompressed and is handled according to the decompression information to write into FLASH chip, and then the result is returned, and it is decided to continue or re-inject, to realize fast reconfiguration of data.The method can improve the success rate of reconfiguration.

Description

Technical Field

[0001] The present application relates to the field of radio transmission technology, and in particular to a method for high-reliability and rapid reconstruction of satellite-borne software. Background Art

[0002] Programmable logic devices and digital signal processors (DSPs), such as FPGAs, DSPs, CPUs, and ARM processors, are the preferred choice for onboard processors due to their high flexibility, high performance, short development cycles, and low cost. The processor can load program files pre-stored in non-volatile memory, such as FLASH, to implement corresponding functions. To further enhance the flexibility and scalability of onboard processors, most current spacecraft feature software reconfiguration capabilities, enabling software upgrades to the onboard processor by modifying the program files in the FLASH. During onboard software reconfiguration, the modified original executable file is typically injected into the spacecraft via a ground-based communication link using ground-based injection equipment. After receiving the executable file, the spacecraft writes it to its internal FLASH memory, completing the software upgrade.

[0003] Traditional onboard computers typically utilize high-quality components. For the critical function of reconfiguration, single-event-proof antifuse FPGAs, coupled with high-grade radiation-hardened processors, are typically used. However, the use of high-grade components significantly increases product development costs. Furthermore, the FPGA+processor architecture results in bulky and power-hungry hardware circuits, further increasing development costs. For future large-scale, low-Earth orbit constellations, traditional hardware architectures struggle to meet the requirements in terms of size, power consumption, and cost. Furthermore, as spacecraft functionality becomes increasingly complex, the size of onboard software is rapidly increasing. For example, the ZYNQ7000-100 FPGA, a popular FPGA, can reach 17MB. Due to the limited bandwidth of the satellite-to-ground link, the onboard software upload process often takes a long time. The rapid growth of onboard software further exacerbates this problem. Traditional reconfiguration methods using raw executable files are unable to meet the rapid iteration requirements of future spaceflight. Therefore, the development of fast reconfiguration methods is urgently needed. For example, a rapid reconstruction method based on file compression can effectively reduce the size of the executable file by comparing it with the original executable file stored in FLASH and losslessly compressing the differences, thereby improving reconstruction efficiency. However, the original file may differ significantly from the file to be injected, making compression efficiency insufficient. In addition, due to the influence of space radiation, the executable file stored in FLASH may be flipped, resulting in errors in the comparison results between the injected file and the original executable file, and the risk of program reconstruction failure. Summary of the Invention

[0004] Based on this, it is necessary to provide a reliable and fast reconstruction method suitable for onboard processors that can improve the reconstruction success rate in response to the above technical problems.

[0005] A high-reliability and rapid reconstruction method for onboard software, the method comprising:

[0006] The onboard processor of a spacecraft is constructed using a SmartFusion2 chip, a FLASH module, a DDR, and an SRAM-type FPGA. The FLASH module includes multiple FLASH chips. The onboard processor sends instructions to the spacecraft to read the executable file of the corresponding software configuration item in the FLASH chip, perform verification, and return the verification value.

[0007] Based on the checksum returned by the onboard processor, the program version and data in the onboard FLASH are confirmed to be correct. The executable files that need to be reconstructed on-orbit are compared to generate a reconstruction difference data packet. The data block size of the file segmentation is determined.

[0008] The original executable file data packet to be reconstructed and the reconstructed difference data packet are divided into data blocks and compressed separately. The compression ratio is calculated. The data blocks with high compression ratio are selected one by one based on the compression ratio. The final file to be injected is composed in sequence and decompression information is generated to mark each data block as the original reconstructed data or the reconstructed difference data.

[0009] The decompressed information and the final file to be injected are injected into the spacecraft via the satellite-to-ground link in units of data blocks. After receiving the injected information, the onboard processor decompresses the injected information in units of data blocks and determines the processing method for writing the current data block into the FLASH chip based on the injected decompressed information. After writing the injected information into the FLASH chip, the data block processing result is returned.

[0010] The decision to continue or re-upload is based on the processing results returned by the onboard processor until all data blocks are uploaded to achieve rapid data reconstruction.

[0011] The above-mentioned high-reliability and rapid reconstruction method for onboard software utilizes the radiation-immune SmartFusion2 chip as a dedicated reconstruction unit, leveraging its internal ARM Cortex-M3 unit to perform protocol parsing and process scheduling. This replaces the traditional anti-fuse FPGA + radiation-hardened processor architecture, improving the integration of the reconstruction circuitry while effectively reducing size, power consumption, and cost while ensuring radiation resistance. Furthermore, the onboard processor reads the executable file from the FLASH chip and verifies the returned checksum, pre-checking the program version and data correctness in the onboard FLASH. This prevents reconstruction failures caused by errors in the original file, thus ensuring the reliability of the reconstruction foundation from the source. The addition of a data verification step for the original onboard FLASH effectively prevents reconstruction process anomalies caused by single-event upsets in the onboard FLASH. The executable files to be reconstructed on-orbit are compared to generate a reconstructed difference data packet. The original and difference data packets are then compressed in blocks, and the data blocks are selected based on the compression ratio to form the final file to be injected. This method not only uses differential data to reduce the amount of transmission, but also reduces the risk of transmission errors by rationally selecting data blocks with high compression rates. At the same time, it generates decompression information to clarify the properties of each data block, which helps to accurately process when writing to FLASH, and improves the accuracy and efficiency of data transmission and processing during the reconstruction process. Annotation, decompression and writing to FLASH are performed in units of data blocks, and the processing results are returned. The decision to continue or re-annotate is based on the results. This block operation and timely feedback mechanism makes it possible to quickly locate specific data blocks when problems occur, and to re-annotate and correct them in time, rather than restarting the entire reconstruction process after failure. This effectively improves the success rate and fault tolerance of reconstruction, ensuring that even if problems occur in some data blocks, the overall reconstruction task can be completed by re-annotating the data blocks. In addition, this application also supports compression reconstruction of all programs. Compression reconstruction is not limited to files of a specific size or type. Any program, configuration parameters, etc. can be reconstructed into the configuration Flash through compression reconstruction. Out-of-order transmission is supported. The reconstructed data frame contains the current data sequence number, which represents the data's offset position in the transmitted file. The reconstruction process supports out-of-order transmission of data frames. Lost data frames and erroneous program sectors can be detected via telemetry. Breakpoint resumability is supported. The ground can obtain the current status of the reconstructor and the verification status of each sector through telemetry, allowing the transmission to resume after the transmission interruption is restored. Even if a power outage occurs during the transmission interruption, the sector verification status can be used to confirm the sector that needs to be retransmitted. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] Figure 1 1 is a flow chart of a method for high-reliability and rapid reconstruction of onboard software in one embodiment;

[0013] Figure 2is a structural block diagram of a spaceborne processor in one embodiment;

[0014] Figure 3 A system block diagram for generating a file to be injected in one embodiment;

[0015] Figure 4 A flowchart of a process for generating a compressed file and decompressing information on the ground when the onboard FLASH is verified to be correct in one embodiment;

[0016] Figure 5 A flowchart of a process for generating a compressed file and decompressing information on the ground when an onboard FLASH checksum error occurs in another embodiment;

[0017] Figure 6 FIG. 4 is a flowchart of processing injection files on-board in one embodiment. DETAILED DESCRIPTION

[0018] In order to make the purpose, technical solutions and advantages of this application more clear, the following further describes this application in detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain this application and are not intended to limit this application.

[0019] In one embodiment, Figure 1 As shown, a high-reliability and rapid reconstruction method for onboard software is provided, comprising the following steps:

[0020] Step 102, using SmartFusion2 chip, FLASH module, DDR and SRAM type FPGA to build a satellite processor in the spacecraft; the FLASH module includes multiple FLASH chips; sending instructions to the spacecraft to use the satellite processor to read the executable file of the corresponding software configuration item in the FLASH chip, perform verification and return the verification value.

[0021] The radiation-immune SmartFusion2 chip serves as a dedicated reconstruction unit, with its internal ARM Cortex-M3 unit responsible for protocol parsing and process scheduling. This replaces the traditional architecture and increases the integration of the reconstruction circuitry. Radiation resistance is crucial in space environments. This chip effectively withstands space radiation, reducing the risk of hardware failures caused by radiation, providing a stable hardware foundation for data reconstruction. Compared to traditional hardware architectures susceptible to single-event effects, this significantly improves stability.

[0022] like Figure 2As shown in the figure, the onboard processor is constructed by combining a FLASH module, DDR, and an SRAM-based FPGA. The FLASH module's multiple FLASH chips store executable files for software configuration items, while the DDR and SRAM-based FPGAs support data processing and storage. This combination leverages the strengths of each component, making the onboard processor more efficient in data storage, processing, and transmission, thereby improving reconfiguration success.

[0023] The onboard processor reads the executable file from the FLASH chip and verifies the returned checksum. This checksum verifies the correctness of the program version and data in the onboard FLASH. This process can promptly detect data errors in the FLASH, possibly caused by single-event upsets (SEVs), before reconstruction. This effectively prevents reconstruction anomalies caused by erroneous data and improves reconstruction success rates from the source.

[0024] The verification process in this step includes but is not limited to XOR verification, cumulative sum verification, CRC verification, etc.

[0025] Step 104: confirm whether the program version and data in the onboard FLASH are correct based on the checksum returned by the onboard processor, compare the executable file that needs to be reconstructed on-orbit, generate a reconstruction difference data packet, and determine the data block size of the file segmentation.

[0026] When the onboard FLASH is verified correctly, the processing flow chart of generating compressed files and decompressing information on the ground is as follows: Figure 4 As shown; the processing flow chart of generating compressed files and decompressing information on the ground when the onboard FLASH check error occurs is as follows Figure 5 shown.

[0027] Step 106: Split the original executable file data packet to be reconstructed and the reconstructed difference data packet into data blocks and compress them separately. Calculate the compression ratio. Using the compression ratio as an indicator, select data blocks with high compression ratios one by one. Sequentially compose the final file to be injected. Generate decompression information to mark each data block as the original reconstructed data or the reconstructed difference data.

[0028] Compare the executable files that need to be reconstructed on-orbit and generate a reconstructed difference data packet. Segment and compress the original executable file data packet and the reconstructed difference data packet in units of data blocks. After calculating the compression ratio, select the data blocks with high compression ratio block by block to form the final file to be injected, and generate decompression information to mark the properties of the data blocks. This method can reduce the size of the injection package on the reconstruction software and reduce the data transmission requirements for the satellite-to-ground communication link. At the same time, by selecting the optimal compression method, the error probability in the data transmission process is reduced, and each data block can be accurately processed according to the decompression information, thereby improving the accuracy and efficiency of data processing. Among them, the system block diagram for the generation of the file to be injected is shown as follows: Figure 3 shown.

[0029] Reconstructed data frames contain data sequence numbers representing offset positions, supporting out-of-order transmission of data frames. Even in complex space communication environments where the data transmission order is disrupted, data can be accurately reassembled based on the sequence numbers. Lost data frames and erroneous program sectors can be detected through telemetry, facilitating timely remedial measures and ensuring the integrity of data reconstruction.

[0030] Step 108: Inject the decompressed information and the final file to be injected into the spacecraft via the satellite-to-ground link in units of data blocks. After receiving the injected information, the onboard processor decompresses the injected information in units of data blocks, and determines the processing method when writing the current data block into the FLASH chip based on the injected decompressed information. After writing the injected information into the FLASH chip, the data block processing result is returned.

[0031] The injection information supports injection in any packet order.

[0032] Step 110: Continue or re-upload the data according to the processing result returned by the onboard processor until all data blocks are uploaded to achieve rapid data reconstruction.

[0033] The ground can obtain the current status of the reconstructor and the verification status of each sector through telemetry, and can continue to inject after the transmission interruption is restored. Even if a power outage occurs, the sector verification status can be used to confirm the sector that needs to be retransmitted. This mechanism can effectively deal with possible interruptions in space communications, avoid reconstruction failures caused by transmission interruptions, and greatly improve the success rate of reconstruction. Among them, the processing flow chart of the injection file on the satellite is as follows Figure 6 shown.

[0034] The above-mentioned high-reliability and rapid reconstruction method for onboard software utilizes the radiation-immune SmartFusion2 chip as a dedicated reconstruction unit, leveraging its internal ARM Cortex-M3 unit to perform protocol parsing and process scheduling. This replaces the traditional anti-fuse FPGA + radiation-hardened processor architecture, improving the integration of the reconstruction circuitry while effectively reducing size, power consumption, and cost while ensuring radiation resistance. Furthermore, the onboard processor reads the executable file from the FLASH chip and verifies the returned checksum, pre-checking the program version and data correctness in the onboard FLASH. This prevents reconstruction failures caused by errors in the original file, thus ensuring the reliability of the reconstruction foundation from the source. The addition of a data verification step for the original onboard FLASH effectively prevents reconstruction process anomalies caused by single-event upsets in the onboard FLASH. The executable files to be reconstructed on-orbit are compared to generate a reconstructed difference data packet. The original and difference data packets are then compressed in blocks, and the data blocks are selected based on the compression ratio to form the final file to be injected. This method not only uses differential data to reduce the amount of transmission, but also reduces the risk of transmission errors by rationally selecting data blocks with high compression rates. At the same time, it generates decompression information to clarify the properties of each data block, which helps to accurately process when writing to FLASH, and improves the accuracy and efficiency of data transmission and processing during the reconstruction process. Annotation, decompression and writing to FLASH are performed in units of data blocks, and the processing results are returned. The decision to continue or re-annotate is based on the results. This block operation and timely feedback mechanism makes it possible to quickly locate specific data blocks when problems occur, and to re-annotate and correct them in time, rather than restarting the entire reconstruction process after failure. This effectively improves the success rate and fault tolerance of reconstruction, ensuring that even if problems occur in some data blocks, the overall reconstruction task can be completed by re-annotating the data blocks. In addition, this application also supports compression reconstruction of all programs. Compression reconstruction is not limited to files of a specific size or type. Any program, configuration parameters, etc. can be reconstructed into the configuration Flash through compression reconstruction. Out-of-order transmission is supported. The reconstructed data frame contains the current data sequence number, which represents the data's offset position in the transmitted file. The reconstruction process supports out-of-order transmission of data frames. Lost data frames and erroneous program sectors can be detected via telemetry. Breakpoint resumability is supported. The ground can obtain the current status of the reconstructor and the verification status of each sector through telemetry, allowing the transmission to resume after the transmission interruption is restored. Even if a power outage occurs during the transmission interruption, the sector verification status can be used to confirm the sector that needs to be retransmitted.

[0035] In one embodiment, the SmartFusion2 chip serves as the reconstruction unit, and its internal ARM Cortex-M3 unit runs the reconstruction application, which is responsible for receiving and parsing reconstruction-related data frames, decompressing compressed files, and controlling the writing of source program files to the FLASH chip; the FPGA unit in the SmartFusion2 chip completes interface conversion, data interaction and timing control with the FLASH chip, SRAM-type FPGA and other devices.

[0036] In one embodiment, the FLASH chip is mounted on the SmartFusion2 chip, and the external processor can obtain the FLASH chip content in a read-only manner through the SmartFusion2 chip via the inter-board interconnection line; only the reconstruction application has write permission to the Flash chip, ensuring the data security of the reconstructed content, and at the same time providing reliable reconstruction data security for the multi-processor hardware structure.

[0037] In one embodiment, the process of determining the data block size of the file segmentation includes:

[0038] When determining the data block unit size of the file segmentation, it is selected by limited traversal query. The data block size is 2 times the size of each sector of the FLASH chip. N times, where N is a positive integer starting from 0, 2 N The maximum value of N should not exceed the size of the file to be reconstructed, and the value of N should be selected with the goal of minimizing the file size after mixed compression.

[0039] In a specific embodiment, it is assumed that the original reconstructed file is cut to generate data blocks numbered X1, X2, X3, ..., Xi, and the reconstructed difference file is cut to generate data blocks Y1, Y2, Y3, ..., Yi. The generated data blocks are compressed in a lossless manner to generate x1, x2, x3, ..., xi and y1, y2, y3, ..., yi, respectively. x1 and y1, x2 and y2, ..., xi and yi are compared, and the smaller file is selected, denoted as z1, z2, z3, ..., zi. The selected compressed files are then concatenated to form a complete compressed file. N is set to 1, 2, 3, and so on, up to the maximum value of N, with N taking different values ​​each time, to obtain the corresponding compressed files. The smallest compressed file is selected as the final file to be injected. The selection method for each data block is recorded, with the original executable file being 0 and the reconstructed difference file being 1, to form decompression information.

[0040] The steps of lossless compression include:

[0041] (1) Initialize the dictionary. At the beginning, the dictionary contains all possible single strings, and the current prefix K is empty;

[0042] (2) Read the first character of the compressed data as the prefix string K;

[0043] (3) Read the next character as the extended character x and determine whether Kx is in the current dictionary. If so, K = Kx. Otherwise, output the dictionary index of K as the output codeword, store Kx in the dictionary, and set K = x.

[0044] (4) Determine whether there are any characters in the compressed data that have not been encoded. If so, repeat step (3). Otherwise, output the dictionary index of K.

[0045] In one embodiment, the process of calculating the compression ratio includes:

[0046] Calculating a compression ratio based on the size of the original data block and the size of the compressed data block, and calculating a compression ratio adjustment coefficient based on the compression ratio and a preset control compression ratio curve shape parameter;

[0047] A time penalty coefficient is calculated based on the time required to compress a data block and the time required to decompress the data block;

[0048] Calculating a data integrity check value during the decompression process according to a CRC algorithm, and constructing an integrity reward function using the data integrity check value and the number of data errors detected during the decompression process;

[0049] The compression ratio is calculated using the compression ratio adjustment coefficient, the time penalty coefficient, the integrity reward function and the original data block size.

[0050] In a specific embodiment, a compression ratio adjustment factor is calculated based on the original and compressed data block sizes and the parameters that control the compression ratio curve shape. This allows for precise control of compression quality, optimizes transmission efficiency, and indirectly facilitates reconstruction. Compression and decompression time are considered to balance time costs, improve overall efficiency, and indirectly impact the reconstruction rate. Data accuracy is ensured by using CRC checksums and the number of decompression errors. An integrity reward function is constructed to provide feedback and optimize data block selection, improving reconstruction success. Finally, the compression ratio is calculated by combining the compression ratio adjustment factor, time penalty factor, integrity reward function, and original data block size. This allows for a comprehensive assessment of data block quality, optimizes each reconstruction step, and ultimately improves the data reconstruction rate.

[0051] In one embodiment, the compression ratio adjustment coefficient is calculated based on the compression ratio and a preset control compression ratio curve shape parameter, including:

[0052] The compression ratio adjustment coefficient is calculated based on the compression ratio and the preset control compression ratio curve shape parameter.

[0053]

[0054] in, represents the compression ratio, Indicates the original data block size, Indicates the size of the compressed data block. and Represents the parameters that control the shape of the compression ratio curve.

[0055] In one embodiment, the time penalty coefficient is calculated based on the time required to compress the data block and the time required to decompress the data block, including:

[0056] The time penalty coefficient is calculated based on the time required to compress the data block and the time required to decompress the data block:

[0057]

[0058] in, Indicates the time required to compress the data block, Indicates the time required to decompress the data block, and Represents the time weight parameter.

[0059] In one embodiment, constructing an integrity reward function using the data integrity check value and the number of data errors detected during decompression includes:

[0060] The integrity reward function is constructed using the data integrity check value and the number of data errors detected during the decompression process:

[0061]

[0062] in, Indicates the number of data errors detected during decompression. and represents the integrity weight parameter, Indicates the data integrity check value, Indicates the data integrity value of the current original data block.

[0063] In one embodiment, the compression ratio is calculated using the compression ratio adjustment coefficient, the time penalty coefficient, the integrity reward function, and the original data block size, including:

[0064] The compression ratio is calculated using the compression ratio adjustment coefficient, time penalty coefficient, integrity reward function and original data block size.

[0065]

[0066] in, Indicates the compression ratio adjustment coefficient, represents the time penalty coefficient, represents the completeness reward function, Indicates the original data block size.

[0067] In one embodiment, a method of processing a current data block when writing the injected decompressed information into the FLASH chip is determined based on the injected decompressed information, and the injected information is written into the FLASH chip, including:

[0068] When the onboard processor writes data to the FLASH chip, it performs different processing according to the decompression information of the data packet. If the current data block is original reconstructed data, it is directly written to the FLASH chip after decompression; if the current data block is differentially reconstructed data, it is first read from the corresponding address of the FLASH chip, and then XORed with the decompressed differentially reconstructed data, and the XOR result is written to the FLASH.

[0069] It should be understood that although Figure 1 The steps in the flowchart are shown in sequence as indicated by the arrows, but these steps are not necessarily executed in the order indicated by the arrows. Unless otherwise specified in this document, there is no strict order restriction for the execution of these steps, and these steps can be executed in other orders. In addition, Figure 1 At least part of the steps may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily performed at the same time, but can be performed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be performed in turn or alternately with other steps or at least part of the sub-steps or stages of other steps.

[0070] The technical features of the above embodiments can be combined arbitrarily. To make the description concise, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0071] The above-described embodiments merely represent several implementation methods of the present application. While the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the invention. It should be noted that a person of ordinary skill in the art may make various modifications and improvements without departing from the spirit of the present application, and such modifications and improvements are intended to fall within the scope of protection of the present application. Therefore, the scope of protection of the present application shall be determined by the appended claims.

Claims

1. A high-reliability and rapid reconstruction method for onboard software, characterized in that: The method comprises: A spacecraft-mounted processor is constructed using a SmartFusion2 chip, a FLASH module, a DDR, and an SRAM-type FPGA; the FLASH module includes multiple FLASH chips; Send instructions to the spacecraft to use the onboard processor to read the executable file of the corresponding software configuration item in the FLASH chip, perform verification and return the verification value; Based on the checksum returned by the onboard processor, the program version and data in the onboard FLASH are confirmed to be correct. The executable files that need to be reconstructed on-orbit are compared to generate a reconstruction difference data packet. The data block size of the file segmentation is determined. The original executable file data packet to be reconstructed and the reconstructed difference data packet are divided into data blocks and compressed separately. The compression ratio is calculated. The data blocks with high compression ratio are selected one by one based on the compression ratio. The final file to be injected is composed in sequence and decompression information is generated to mark each data block as the original reconstructed data or the reconstructed difference data. In units of data blocks, the decompressed information and the final file to be injected are injected into the spacecraft via the satellite-to-ground link; After receiving the injected information, the onboard processor decompresses the injected information in data blocks and decides how to process the current data block when writing it to the FLASH chip based on the injected decompressed information. After writing the injected information to the FLASH chip, the processor returns the data block processing result. The decision to continue or re-upload is based on the processing results returned by the onboard processor until all data blocks are uploaded to achieve rapid data reconstruction. Based on the injected decompressed information, the processing method for writing the current data block into the FLASH chip is determined. The injected information is written into the FLASH chip, including: When the onboard processor writes data to the FLASH chip, it performs different processing based on the decompression information of the data packet. If the current data block is original reconstructed data, it is directly written to the FLASH chip after decompression. If the current data block is differentially reconstructed data, it first reads the data from the corresponding address of the FLASH chip, then XORs it with the decompressed differentially reconstructed data, and writes the XOR result to the FLASH. The process of calculating the compression ratio includes: Calculating a compression ratio based on the size of the original data block and the size of the compressed data block, and calculating a compression ratio adjustment coefficient based on the compression ratio and a preset control compression ratio curve shape parameter; A time penalty coefficient is calculated based on the time required to compress a data block and the time required to decompress the data block; Calculating a data integrity check value during the decompression process according to a CRC algorithm, and constructing an integrity reward function using the data integrity check value and the number of data errors detected during the decompression process; The compression ratio is calculated using the compression ratio adjustment coefficient, the time penalty coefficient, the integrity reward function and the original data block size.

2. The method according to claim 1, wherein The SmartFusion2 chip serves as a reconstruction unit, and its internal ARM Cortex-M3 unit runs the reconstruction application, which is responsible for receiving and parsing reconstruction-related data frames, decompressing compressed files, and controlling the writing of source program files to the FLASH chip; the FPGA unit in the SmartFusion2 chip completes interface conversion, data interaction, and timing control with the FLASH chip, SRAM-type FPGA, and other devices.

3. The method according to claim 1, characterized in that The FLASH chip is mounted on the SmartFusion2 chip, and the external processor can obtain the FLASH chip content in a read-only manner through the inter-board interconnection line and the SmartFusion2 chip; only the reconstruction application has the write permission of the Flash chip, ensuring the data security of the reconstructed content, and at the same time providing reliable reconstruction data security for the hardware structure of multiple processors.

4. The method according to claim 1, wherein The process of determining the data block size for file segmentation includes: When determining the data block unit size of the file segmentation, it is selected by limited traversal query. The data block size is 2 times the size of each sector of the FLASH chip. N times, where N is a positive integer starting from 0, 2 N The maximum value of N should not exceed the size of the file to be reconstructed, and the value of N should be selected with the goal of minimizing the file size after mixed compression.

5. The method according to claim 1, wherein The compression ratio adjustment coefficient is calculated based on the compression ratio and a preset control compression ratio curve shape parameter, including: The compression ratio adjustment coefficient is calculated based on the compression ratio and the preset control compression ratio curve shape parameter. in, represents the compression ratio, Indicates the original data block size, Indicates the size of the compressed data block. and Represents the parameters that control the shape of the compression ratio curve.

6. The method according to claim 1, wherein The time penalty coefficient is calculated based on the time required to compress the data block and the time required to decompress the data block, including: The time penalty coefficient is calculated based on the time required to compress the data block and the time required to decompress the data block: in, Indicates the time required to compress the data block, Indicates the time required to decompress the data block, and Represents the time weight parameter.

7. The method according to claim 1, wherein The data integrity check value and the number of data errors detected during the decompression process are used to construct an integrity reward function, including: The integrity reward function is constructed using the data integrity check value and the number of data errors detected during the decompression process: in, Indicates the number of data errors detected during decompression. and represents the integrity weight parameter, Indicates the data integrity check value, Indicates the data integrity value of the current original data block.

8. The method according to claim 1, wherein The compression ratio is calculated using the compression ratio adjustment coefficient, the time penalty coefficient, the integrity reward function, and the original data block size, including: The compression ratio is calculated using the compression ratio adjustment coefficient, time penalty coefficient, integrity reward function and original data block size. in, Indicates the compression ratio adjustment coefficient, represents the time penalty coefficient, represents the completeness reward function, Indicates the original data block size.

Images