On-orbit reconstruction and multi-version management system of satellite operation software

Abstract

The application discloses an on-orbit reconstruction and multi-version management system of satellite software, and belongs to the technical field of development and maintenance of satellite software. The system solves the problems of low reconstruction efficiency, insufficient fault tolerance and scattered version management of the satellite software. The system comprises a difference calculation module, a compression and coding module, a data receiving and checking module and a multi-version storage management module. Based on the executable files of the old version and the new version of the satellite software, the BSDiff incremental updating algorithm is used for difference calculation to generate program difference blocks. The program blocks uploaded on the ground are compressed again, and the compressed difference blocks are decompressed on the satellite. According to the satellite-ground communication protocol, the reconstruction data files are received, the package data is combined into complete reconstruction files, the difference blocks and the original version are combined to construct a new program, and the program is checked. The storage management of the multiple version programs on the satellite, data moving between the versions and selection of the starting version are performed.

Description

Technical Field

[0001] This invention belongs to the field of development and maintenance technology of space service software, specifically relating to an on-orbit reconfiguration and multi-version management system for space service software. Background Technology

[0002] Satellite management software is a core component of the integrated electronic system of a satellite. It serves as the central control and information processing hub supporting on-orbit functionality and ensuring data exchange between the satellite and ground stations, directly determining the stability and mission execution capabilities of the satellite's on-orbit operation. With the rapid development of aerospace technology, the on-orbit service life of satellites has been significantly extended, and the on-orbit operating environment and mission requirements continuously change over time. Simultaneously, modern satellite management software undergoes iterative upgrades and its complexity continues to increase. Ground testing, limited by scenarios, environments, and testing cycles, cannot fully replicate the complex and ever-changing on-orbit conditions, making it difficult to thoroughly identify deep-seated program defects. Therefore, satellite management software needs continuous on-orbit version updates. Reconfiguration capability has become a crucial foundation for the entire lifecycle operation of a satellite, a key means to compensate for shortcomings in ground testing, adapt to changes in on-orbit status, and ensure the long-term reliable service of the satellite.

[0003] Post-orbit satellite software updates primarily rely on program uploads from ground control stations. However, the control arc resources during satellite operation are extremely limited, with a single effective uplink transmission window lasting only about ten minutes, resulting in extremely tight timeframes for software uploads. Furthermore, the satellite-to-ground communication link is unstable, making data errors, frame loss, and transmission interruptions highly likely during on-orbit transmission, severely impacting the efficiency and security of on-orbit software updates. Existing on-orbit reconfiguration solutions suffer from the following main pain points: 1. The full upload mode has low update efficiency and consumes a lot of telemetry and control resources: The traditional full upload method requires transmitting the complete new version of the program binary file to the satellite via the space-to-ground link. As the size of the satellite operation software continues to increase, the transmission time of the complete version has increased significantly, and it is often difficult to complete a complete program upload in a single telemetry and control arc. In addition, the long-term transmission of large amounts of data on unreliable links significantly increases the probability of bit errors and frame loss, further reducing the update success rate and making it difficult to meet the operation and maintenance requirements for rapid on-orbit response.

[0004] 2. Difference update methods are limited by statement-level granularity, leading to a sharp increase in patch size during large-scale modifications: To reduce the amount of data added, existing methods mostly employ statement-level difference update strategies, which are only applicable to local modifications such as variable values ​​and constant values ​​where the number of bytes remains unchanged. Such modifications do not cause address reordering in subsequent regions of the executable file, resulting in a relatively small difference file size. However, when new statements or functions are added to the program, or the code structure is adjusted, the instruction addresses, pointer addresses, and register addresses after the modification location will undergo large-scale offsets. Traditional byte-by-byte difference algorithms treat these large address offsets as independent new data, causing the generated patch file size to increase dramatically, approaching or even exceeding the amount of data added with full data, thus negating the advantages of difference updates.

[0005] 3. Difference updates heavily rely on the integrity of the algorithm and the baseline version, lacking the redundancy capability for flexible switching between full and difference updates: Difference reconstruction uses the old version of the program as the baseline for difference calculations. If, during on-orbit operation, anomalies such as single-event flips cause damage to parts of the old version of the program or abnormal version information, difference calculations will fail to execute correctly, and the reconstruction process will be interrupted. Existing solutions lack a redundancy mechanism for flexible switching between full and difference updates. When difference updates cannot be performed, it is impossible to quickly revert to full reconstruction to restore normal system operation, resulting in insufficient on-orbit fault tolerance.

[0006] 4. Lack of unified maintenance capabilities for multi-version management, resulting in high costs for version consistency maintenance: To improve reliability, satellite management software typically stores multiple version backups on-board, involving the management of various states such as the version to be launched, the currently launched version, and the default launched version. Under current solutions, after a version update is completed, maintaining consistency with other backup versions often requires re-uploading the same program, leading to a waste of telemetry and control resources. Furthermore, the program verification, version migration, and launch state switching between versions lack unified command-line scheduling capabilities, resulting in cumbersome operation processes, low reliability, and difficulty in meeting the frequent version management needs of long-term, large-scale constellation operations. Summary of the Invention

[0007] To address the shortcomings of the existing technologies, this invention proposes an on-orbit reconfiguration and multi-version management system for space service software. Through the collaborative design of four modules—difference calculation, compression encoding and decoding, data reception and verification, and version management—it systematically solves the problems of low on-orbit reconfiguration efficiency, insufficient fault tolerance, and fragmented version management.

[0008] The module includes a difference calculation module, a compression encoding / decoding module, a data receiving and verification module, and a multi-version storage management module. The difference calculation module is deployed on the ground. Based on the old and new versions of the satellite software executable files, it uses the BSDiff incremental update algorithm to calculate differences and generate program difference blocks. The compression and encoding / decoding module performs secondary compression on the uploaded program blocks on the ground and decompresses the compressed difference blocks on the satellite. The data receiving and verification module is deployed on the satellite. It receives reconstructed data files according to the satellite-ground communication protocol, combines the data packets into a complete reconstructed file, combines the received difference blocks with the original version to build a new program, and performs program verification. The multi-version storage management module is responsible for the storage management of multiple versions of the program on the satellite, data migration between versions, and selection of the startup version.

[0009] Furthermore, the operations performed in the difference calculation module include constructing an array of old file suffixes, searching for the longest match segment by segment in the new file, expanding the approximate match, and encapsulating the difference block.

[0010] Furthermore, the old file suffix array is constructed: the executable files of the new and old versions of the Star Service software are treated as byte sequences, and a lexicographically ordered suffix array is constructed for the old files, so as to realize the binary matching and positioning of the substrings of the new files in the old files; Longest Match Search in New File Segment by Segment: Traverse the new file, find the longest matching segment of the byte sequence based on the suffix array, eliminate redundant matches through the eight-byte difference filtering rule, and accurately define the effective matching interval; Approximate matching extension: The exact matching interval is extended bidirectionally, with a byte matching ratio of no less than 50% as a constraint, dividing the unmodified block and the source code modified block to form an independent approximate matching interval; Difference block encapsulation: Integrates matching and difference data, encapsulates difference blocks containing three areas: control flow, difference data, and additional data, and achieves accurate reconstruction from old files to new files through corresponding instructions.

[0011] Furthermore, the operations performed in the compression encoding and decoding module include Burrows-Wheeler transform, Move-to-Front encoding, Run-Length encoding, Huffman encoding, and on-board decompression.

[0012] Furthermore, the Burrows-Wheeler transformation: performing the Burrows-Wheeler transformation on the byte sequence of the program's difference blocks sorts all cyclic shifts in the data stream, causing similar characters to cluster together; Move-to-Front encoding: Performs Move-to-Front encoding on the output data of the Burrows-Wheeler transform, replacing the byte index and updating the list based on a 256-byte ordered table; Run-Length Encoding: Run-Length encoding is applied to Move-to-Front encoded output data, replacing consecutive repeating character sequences with combinations of characters and repetition counts; Huffman coding: Based on the frequency of byte occurrence in the Run-Length encoded output data, an optimal prefix coding tree is constructed, and long and short codes are allocated according to the frequency. Finally, a compressed difference block data stream is generated, which is called a compressed difference block. On-board decompression: After merging the complete compressed difference blocks on-board, multi-level decoding and Burrows-Wheeler inverse transformation are performed in reverse to restore the original program difference blocks without loss.

[0013] Furthermore, the operations performed in the data receiving and verification module include reconstructing process initiation and baseline file reading, data block packet reception and packet-by-packet verification, compressed difference block merging and decompression, difference decoding and new file construction, full-volume uploading mode processing, and program integrity and consistency verification.

[0014] Furthermore, the reconstruction process is initiated and the baseline file is read: after receiving the read command, the satellite enables the upload function, reads the specified version of the program data into the reconstruction buffer, records the program length, and establishes the difference upload baseline file; Data block packet reception and packet-by-packet verification: The satellite receives various types of data command packets from the ground uplink, performs CRC verification on each data packet, sorts and buffers the data and sends an acknowledgment if the verification passes, and reports and waits for the data to be retransmitted if there is an error. Combining and decompressing compressed difference blocks: After receiving all data packets, they are concatenated into complete compressed difference blocks according to their packet numbers. The compression encoding and decoding module is then called to decompress the blocks using the BZip2 algorithm, restoring the original program difference blocks. Difference decoding and new file construction: Based on the ADD and INSERT instructions in the difference block control flow area, the old data difference overlay and new data writing operations are completed respectively, and the new version program file is constructed by processing each instruction; Full upload mode processing: This backup mode is enabled for scenarios where the old program on the satellite is damaged and cannot be used as a baseline. The full program is compressed and uploaded. The satellite automatically recognizes the compression mark and skips the difference decoding process. Program integrity and consistency verification: Compare the CRC check value and valid length of the new program file. If the verification passes, write it to storage and read it back for verification. If the verification fails, report the error and wait for the ground to re-upload data.

[0015] Furthermore, the operations performed in the multi-version storage management module include starting version determination and program loading, refactoring program writing and critical information updating, starting version switching, and version migration.

[0016] Furthermore, the startup version determination and program loading are as follows: the satellite is powered on and the key version parameters stored in the three-mode redundancy storage are read. The startup version is determined by a two-out-of-three vote, the program is loaded and CRC verification is completed. In case of an anomaly, the system will revert to the default startup version. Reconstructing program writing and updating key information: Write the new program that has passed the verification to the corresponding storage area and read it back for verification. Update the program length, CRC check value and startup status of this version in a three-modal redundancy manner. Startup version switching: Modify the on-board version number to be started through a three-mode redundancy method, update the startup configuration, and enable the device to load the specified version program the next time it is powered on; Version migration: In response to ground instructions, the source version program is completely copied to the target version storage area. Only the program content is copied, and the target version parameters are subsequently verified and updated by the ground.

[0017] Furthermore, the triple redundancy specifically means that each parameter is written to three storage devices.

[0018] The beneficial effects of the system described in this invention are as follows: 1. Significantly reduce the amount of data transmitted: The difference calculation module adopts the BSDiff incremental update algorithm, which treats the executable file as an opaque byte stream. By expanding through the longest matching and approximate matching of the suffix array, it makes full use of the sparse changes in the second-order variable region of the executable file and the consistent address displacement. The generated program difference block is much smaller than that of the traditional byte-by-byte difference method. The compression encoding and decoding module further compresses the program difference block twice through the BZip2 algorithm, which greatly reduces the amount of data transmitted between the satellite and the ground.

[0019] 2. Improve on-orbit update efficiency: The program difference block is significantly reduced in size after secondary compression, which allows more program content to be updated within a limited number of telemetry and control cycles, shortens the time required for on-orbit reconfiguration of satellite software, and improves the satellite's ability to respond quickly to software problems.

[0020] 3. Provides full reconfiguration redundancy capability: While retaining the efficient difference uploading method, the reconfiguration processing module supports full uploading mode. When anomalies such as single-event upsets occur in orbit, causing the old version of the program to be damaged and unable to be used as a difference benchmark, the program can be restored through full uploading, ensuring in-orbit reliability.

[0021] 4. Achieve efficient multi-version management: The multi-version storage management module achieves consistency and synchronization between backup versions through a version migration mechanism, avoiding duplicate uploading of the same program and saving measurement and control resources; it improves the resistance to single-event upsets by using triple redundancy storage of key external storage parameters; and it supports on-orbit version rollback and rapid recovery through a flexible startup version switching mechanism, making it suitable for long-term operation and management of large-scale constellations. Attached Figure Description

[0022] Figure 1 This is an on-orbit reconfiguration architecture diagram of the space service software in an embodiment of the present invention; Figure 2 This is a flowchart illustrating the on-orbit reconfiguration process of the space service software in this embodiment of the invention. Figure 3 This is a flowchart of the difference calculation algorithm in an embodiment of the present invention; Figure 4 This is a schematic diagram of the program version management process in an embodiment of the present invention; Figure 5 This is a diagram of the interface of the auxiliary software for reconstructing the space service program in an embodiment of the present invention. Detailed Implementation

[0023] The technical solution of the present invention will now be clearly and completely described with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the protection scope of the present invention.

[0024] Example 1 This implementation provides an on-orbit reconfiguration and multi-version management system for space service software. The system's strategy is summarized below: 1. Incremental Updates and Secondary Compression Based on Binary Differences Significantly Reduce Upload Data Size: This invention employs the BSDiff incremental update algorithm, treating the old and new versions of the executable file as opaque byte streams. Leveraging the sparse binary differences and consistent address offsets of identical source code blocks within the executable file, it generates program difference blocks significantly smaller than those obtained using traditional byte-by-byte difference methods. Furthermore, secondary compression is applied to these difference blocks, utilizing the highly structured features of the control flow and difference data areas for further compression, resulting in a substantial reduction in the final upload data size. Even when adding statements or adjusting code structure leads to large address offsets, this invention can still generate compact difference patch files, overcoming the limitation of traditional statement-level difference updates where patch size rapidly increases with large-scale modifications.

[0025] 2. A packet-based confirmation upload protocol ensures reliable transmission over unreliable links: This invention designs a program reconstructing remote control command protocol that uploads compressed difference blocks or full program data in fixed-length packets. Each packet undergoes CRC verification on-board, effectively reducing the impact of bit errors and frame loss in the satellite-to-ground communication link on the update success rate. After all data packets are received, the merged complete program undergoes CRC and length verification, is written to external storage, and then readback verification is performed, forming a multi-layered protection link of reception, merging, verification, and writing.

[0026] 3. Supports flexible switching between full upload and differential upload, providing redundancy backup capabilities: While maintaining differential upload as the primary mode, this invention retains the full upload interface as a redundancy backup method. When anomalies such as single-event upsets cause damage to the old version of the program during on-orbit operation, rendering it unusable as a differential baseline, the system can switch to full upload mode, directly uploading the complete new version of the program data, skipping the differential decoding stage, and quickly restoring normal system operation. Flexible switching between multiple modes effectively improves on-orbit fault tolerance and anomaly recovery efficiency.

[0027] 4. A unified multi-version management mechanism is designed to achieve integrated scheduling of version migration, program verification, and startup version selection: This invention stores multiple version backups in onboard non-volatile memory, and stores key information such as the version number to be started, the current startup version number, the default startup version, the program length of each version, and the CRC checksum in external storage, protected by a triple-modal redundancy method. When a version is updated, the program is automatically copied between different version storage areas via version migration commands, without the need to repeatedly upload the same program; by modifying the version number to be started in external storage, the version of the satellite service program loaded at the next restart of the central unit can be specified. The maintenance of each version status, program verification, and startup switching are all uniformly scheduled through remote control commands, avoiding the problems of scattered version management operations and low reliability in existing solutions.

[0028] like Figure 1-2 As shown, Figure 1 It demonstrates the process of on-orbit reconfiguration of satellite management software by ground control, covering the process of creating difference upload packages on the ground, the communication process between satellite and ground, and the internal reconfiguration process and version control parameters of satellite management software. Figure 2 The entire process of satellite-to-satellite reconstruction is demonstrated, including packet-by-packet reception and CRC verification, selection and processing of three modes: differential injection, compressed injection and full injection, program integrity verification and writing to external storage.

[0029] Specific technical solution: This invention uses a set of methods to manage the reconstruction and version management process of space mission software, and optimizes the efficient on-orbit reconstruction and multi-version program maintenance processes of space mission software. The system is divided into four modules: difference calculation, compression and decompression, data reception and verification, and multi-version management. The following sections will introduce each module separately.

[0030] Difference Calculation Module: The difference calculation module is deployed on the ground. Its function is to calculate the differences between the old and new versions of the space service software executable files using the BSDiff incremental update algorithm, and generate program difference blocks, such as... Figure 3This demonstrates the main steps of generating program difference blocks on the ground based on the BSDiff algorithm, including constructing an array of old file suffixes, searching for the longest match segment by segment in the new file, approximate matching expansion, and encapsulating the difference blocks. This module treats the executable file of the space service software as an opaque byte stream, generating difference patch files much smaller than the executable file itself in a platform-independent and software internal structure-independent manner. The process includes the following steps: Step 1: Constructing an array of old file extensions Assume the old version executable file is The file length is The new version executable file is The file length is Both are represented as byte sequences:

[0031]

[0032] For old documents Construct suffix array .set up Indicates from position The suffix substring from the beginning to the end of the file, then It is a length of An integer array that satisfies:

[0033] Right now The starting positions of all suffix substrings in the old file are arranged lexicographically. Based on the suffix array, it is possible to... Locate the new file using binary search within the specified time. Any substring in an old file The longest matching position in the array.

[0034] Step 2: Find the longest match segment by segment in the new file. Traverse new files Based on suffix array right Perform a binary search on each byte sequence to find its counterpart in the old file. The longest matching position and matching length in the range. Assume a matching interval has been found. ,satisfy:

[0035] in This is the starting position in the new file. This is the starting position in the old file. The length of the match. Searching for the next matching interval. At this time, only matches that are a significant improvement over the current match are retained, meaning that at least 8 bytes in the new interval do not satisfy the forward extension relationship:

[0036] This rule avoids recording a large number of redundant matches that only have slight offsets from the previous match, ensuring that the subsequent approximate matching expansion stage can identify truly independent code / data block boundaries.

[0037] Step 3: Approximate Matching Extension Extend each exact match in both forward and backward directions to generate a set of pairwise disjoint approximate matching intervals. Let the exact match... Expand to ,in For backward expansion length, The forward expansion length is defined by the constraint that the byte matching ratio between each suffix in the forward expansion and each prefix in the backward expansion is no less than 50%.

[0038]

[0039] in This is an indicator function. After expansion, the approximate matching interval roughly corresponds to the unmodified code / data block in the source code, while the area not falling into the approximate matching interval corresponds to the modified source code area.

[0040] Step 4: Encapsulating Program Difference Blocks The difference calculation results are encapsulated into program difference blocks. It consists of three parts: control flow region (Ctrl+Data) describes the control information for performing differential reconstruction between the old and new files, including two types of commands: ADD and INSERT; the differential data area. (diff data) records the byte-by-byte difference between corresponding bytes in the old and new files within the approximate matching interval; additional data area. (extra data) records all newly added data in the new file.

[0041] For each approximate matching interval, the ADD directive specifies the old file offset. With copy length Read from the difference data area Difference data in bytes The corresponding range of the new file is obtained by adding them byte by byte:

[0042] The INSERT command specifies the length. Read from the extra data area Each byte is written directly to a new file:

[0043] set up The new file can then be reconstructed from the old file and the program's difference blocks, denoted as... For duplicate content, only the position offset needs to be recorded, which takes up little information in the difference block of the satellite management software; for additional blocks, the content itself needs to be retained, resulting in a larger file size. By generating combined difference blocks for the satellite management software, differentiated program reconstruction can be achieved during subsequent uploading processes. The developers of the satellite management software do not need to focus on the generation of executable files and internal processes; they only need to complete the corresponding logic code modifications and generate difference files.

[0044] Compression encoding / decoding module: Compression encoding and decoding introduces the concepts of compression and decompression into the satellite coding process. It is responsible for performing secondary compression on the uploaded program blocks at the ground end and decompressing the compressed difference blocks at the satellite end, thereby reducing the amount of data transmitted between the satellite and the ground. In the program difference blocks generated by the difference calculation module, the control flow area and the difference data area have strong structured characteristics—most bytes in the difference data area are zero, non-zero values ​​are repeated and concentrated—there is room for further compression. This process uses the Bzip2 algorithm to compress the data and includes the following steps: Step 1: Burrows-Wheeler Transform For program difference blocks The byte sequence is subjected to Burrows-Wheeler Transform (BWT). BWT sorts all the cyclic shifts of the input data stream, clustering identical characters in the output data, thus creating conditions for subsequent encoding. The transformation process is reversible and does not lose any information.

[0045] Step 2: Move-to-Front encoding Move-to-Front (MTF) encoding is performed on the BWT output data. MTF maintains an ordered table containing all 256 possible byte values. Each byte in the input data is replaced with its current index in the ordered table, and then the byte is moved to the head of the table. Identical characters that accumulate after BWT transformation will produce a large number of zero values ​​after MTF encoding, which is beneficial for subsequent run-length encoding.

[0046] Step 3: Run-Length Encoding Run-Length Encoding (RLE) is applied to the MTF output data. RLE replaces consecutively repeating character sequences with combinations of characters and repetition counts, further reducing data size. A large number of zero-value sequences in the MTF output can be efficiently encoded using RLE.

[0047] Step 4: Huffman Coding Huffman coding is performed on the RLE output data. An optimal prefix coding tree is constructed based on the frequency of each byte value in the data; high-frequency bytes are assigned shorter codes, and low-frequency bytes are assigned longer codes, generating a highly compact compressed data stream, denoted as a compressed difference block. .

[0048] Step 5: Onboard decompression The satellite receiver receives all data packets and merges them into a complete array. Then, the reverse operation of the compression process is performed, sequentially carrying out Huffman decoding, RLE decoding, MTF decoding, and BWT inverse transformation to recover the original program difference blocks. :

[0049] The decompressed program difference block is used to build a new executable file for the Star Service program.

[0050] Data receiving and verification module: The data receiving and verification module is deployed on the satellite and is responsible for receiving reconstructed data files according to the satellite-to-ground communication protocol, combining the data packets into a complete reconstructed file, combining the received difference blocks with the original version to construct a new program, and performing program verification. This module defines a set of program reconstructing remote control command protocols, supporting program uploading commands of 512 bytes in length carrying uploading data blocks. This process includes the following steps: Step 1: Refactoring Process Initiation and Baseline File Reading After receiving the file read command, the satellite sets the uploading enable state to enabled, reads the specified version of program data from external storage into the memory program reconstruction buffer, and records the program length of that version as the base file for subsequent difference uploading. The command parameters include program version, valid file length, length reading method, etc.

[0051] Step 2: Data block packet reception and packet-by-packet verification The ground sends data block update commands sequentially. Each command packet carries the data block number and data block content. The command word distinguishes between incrementally uploaded data blocks and fully uploaded data blocks. After each packet is successfully received, the satellite performs a CRC check on the data block: if the check passes, it is sorted by packet number, stored in the buffer, and an acknowledgment telemetry is sent, allowing the ground to send the next packet; if the check fails or the packet number is missing, it reports to the ground via telemetry and waits for retransmission.

[0052] CRC (Cyclic Redundancy Check) is a fast algorithm that generates a short, fixed-length checksum based on the data content.

[0053] Step 3: Merging and Decompressing Compressed Difference Blocks After all data packets are received correctly, they are merged into a complete compressed difference block in order of packet number. The compression and encoding / decompression module then performs BZip2 decompression to recover the original program's difference blocks. .

[0054] Step 4: Difference Decoding and New File Construction Based on program difference blocks Control flow region in The instruction sequence performs the following operations in order: For the ADD instruction, retrieve from the old file... Mid-offset Copy length Match data blocks to a new file Corresponding positions, and overlaying the difference data area. The difference in the data; for the INSERT command, from the extra data area. Read from Each byte is written directly to the new file. Repeat the above process, processing all instructions in the order of the control flow areas, until a new file is created. Build complete.

[0055] Step 5: Full Betting Mode Processing When anomalies such as single-event upsets cause the old version of the program to become corrupted and unusable as a difference reference during on-orbit operation, the system switches to full-load mode. This mode serves as a redundant backup for difference loading, with the complete new version of the program data block being directly loaded from the ground. The satellite skips the difference decoding processes in steps three and four, and directly enters the complete program data received and merged in step two into the verification process in step six. During this process, to avoid excessive telemetry and control resources being consumed by full-load loading, the entire satellite program can also be compressed before loading. The satellite automatically determines whether to decompress the loaded data based on the flag indicating whether the loaded package is compressed.

[0056] Step Six: Program Integrity and Consistency Verification For the new file (in differential upload mode, the newly built version of the program; in full upload mode, the merged complete program data), a CRC checksum is calculated and compared with the expected CRC checksum carried in the file upgrade command. The file's valid length is also verified. Only when both the CRC and length match is the program allowed to be delivered to the multi-version storage management module for writing to the corresponding version storage area in external storage. After writing, a readback verification is performed on the updated program in external storage to ensure the data is correctly written to the specified location. If the verification fails, the error type is reported via telemetry, and the program waits for ground correction before resuming uplink.

[0057] Multi-version storage management module: The multi-version storage management module is responsible for the storage management of multiple versions of the program on the satellite, data migration between versions, and selection of the startup version, ensuring that the reconstructed program can be correctly written to the fixed storage and started safely. For example... Figure 4 The process flow of the multi-version storage management module is demonstrated, including the process of determining the startup version and loading verification based on key parameters of triple redundancy after the entire satellite is powered on, as well as the execution flow of version migration instructions. The satellite operations program stores multiple versions in external storage for mutual backup. This process includes the following steps: Step 1: Startup version confirmation and program loading In addition to storing various versions of the space service program, the external storage also stores the following key parameters: the version number to be launched, the current launch version number, the program length of each version, the CRC checksum of each version, the launch status of each version, and the default launch version. These key parameters are stored using a triple redundancy method, meaning each parameter is written three times, and a two-out-of-three vote is used to determine the valid value during reading. If the three-out-of-three votes result in disagreement, a rollback launch is performed according to the preset default launch version.

[0058] After the satellite is powered on, the bootloader reads the aforementioned key parameters from external storage. After determining the version number to be started through a three-mode vote, it reads the satellite operation program from the corresponding version storage area in external storage into memory and verifies the program based on the program length and CRC check value of that version. If the CRC check passes, execution begins; if the check fails, a rollback to the default startup version is performed to ensure that the system can still operate normally under abnormal conditions.

[0059] Step Two: Refactoring Program Writing and Updating Key Information After the reconstruction processing module completes the construction and verification of the new program, the multi-version storage management module writes the verified program to the corresponding version's storage area in external storage. After writing, a readback verification is performed on the updated program in external storage to ensure the data is correctly written to the specified location. Subsequently, the key parameters of this version in external storage are updated, including program length, CRC checksum, and startup status, also written using triple-modulus redundancy to ensure the reliability of on-orbit storage of key parameters.

[0060] Step 3: Initiate version switching By modifying the version number to be started in external storage, the version of the satellite operation program to be loaded at the next restart of the central unit can be specified. The modification operation is also written to external storage in a triple-modal redundancy manner. Upon the next power-on, the bootloader will read the updated version number to be started, load the corresponding version of the program, and start execution, thereby achieving the purpose of on-orbit repair of software problems, isolation of hardware faults, or improvement of overall satellite performance.

[0061] Step 4: Version Migration Once a version update is complete, if other backup versions need to be consistent with the updated version, there is no need to re-upload the same program. The ground sends a version migration command, with parameters including the source program version and the target program version. After receiving the version migration command, the central unit autonomously performs sequential read and write operations on data blocks from the source version to the target version in external storage, completely copying the source version program to the target version storage area.

[0062] Version migration only copies the program content and does not process the target version's critical parameters. After migration, the ground needs to send a file upgrade command to perform CRC and length checks on the target version. If the checks pass, the critical parameters of the target version in external storage are updated to confirm version consistency. This mechanism effectively avoids duplicate uploading of the same program, saving measurement and control resources.

[0063] Example 2 This embodiment further defines Embodiment 1. This embodiment uses the central computer satellite operation software of a certain type of on-orbit remote sensing satellite as a carrier, and deploys the on-orbit reconfiguration and multi-version management system described in this invention within the program reconfiguration module of the satellite's integrated electronic system. The satellite central computer operation program is stored in eMMC non-volatile memory. After the satellite is powered on, it is moved to DDR by the bootloader and started for execution. The operation program is stored in three versions in eMMC, each undertaking different functions: Version 1 is the initial version, storing the baseline program delivered from the factory as a low-level safety rollback backup; Version 2 is the official version, undertaking routine operational tasks for long-term on-orbit satellite operation; Version 3 is the test version, used for on-orbit verification of newly issued program modifications from the ground. After successful verification, it can be synchronized to the official version via version migration. The key information required for program startup includes the version number to be started, the current startup version number, the program length of each version, the CRC check value of each version, the startup status of each version, and the default startup version. These are stored in external memory in a triple-modal redundancy manner. After the entire satellite is powered on, the boot program determines the startup version number through a two-out-of-three vote, reads the program from the corresponding version area of ​​the eMMC to the DDR, and starts execution after the verification is passed.

[0064] After the satellite entered orbit, a telemetry framing defect was discovered in the official version (version 2) of the satellite service software, requiring on-orbit repair. The ground station first performed a BSDiff difference calculation using the difference calculation module, based on the old version 2 program binary file and the repaired new version program binary file, to generate a program difference block. In this embodiment, the single version of the satellite service program is approximately 1MB in size, with about 200 lines of source code difference between the old and new versions. The program difference block generated by the BSDiff calculation is approximately 45KB. After secondary compression using the BZip2 algorithm by the compression and encoding / decoding module, the compressed difference block size is reduced to approximately 12KB. Only 24 packets of 512B data block update instructions are needed to complete the transmission of all difference data. The ground station first uses the test version (version 3) as the update target and sends a file read command. The onboard reconstruction processing module sets the upload enable bit, reads the old program data from the eMMC version 3 storage area into the DDR program reconstruction buffer as the base file, and then receives the data block update command packet by packet. After each packet is verified by CRC, a confirmation telemetry is sent, and the ground station continues to send the next packet. After all data packets are received and merged, the reconstruction processing module and the compression encoding and decoding module work together to complete the BZip2 decompression and differential decoding, build a new version of the program, and write it into the eMMC version 3 storage area after passing CRC and length verification, and update the key information of version 3 in the external storage.

[0065] After the test version update was completed, the satellite maintained the official version operation. The ground control system switched the version number to be launched to version 3 via remote control commands. The central control unit loaded and executed the version 3 program upon the next restart. After several days of in-orbit operation, the test version program ran stably, and all functions were normal. The ground control system sent a version transfer command, and the onboard multi-version storage management module autonomously copied the program from the eMMC version 3 storage area to the version 2 storage area. Subsequently, a file upgrade command was used to perform CRC and length verification on version 2. After the verification passed, the key information of version 2 in the external storage was updated, and the official version was consistent with the test version. Throughout the process, the difference calculation module, compression encoding and decoding module, reconstruction processing module, and multi-version storage management module worked closely together. The difference data uploading and reconstruction could be completed in just one telemetry and control cycle. Subsequent version switching and transfers were all completed autonomously onboard, without the need to repeatedly upload the same program.

[0066] During ground testing, the satellite-based software reconfiguration auxiliary software simulated the on-orbit update process, automatically completing steps such as package splitting and verification of the uploading program. After successful reconfiguration verification on the ground parallel system, on-orbit reconfiguration was quickly completed. No inconsistencies occurred in the three-mode voting during on-orbit operation regarding the critical startup information in external storage, ensuring the reliability of version management and startup selection. Figure 5As shown in the figure, this diagram illustrates the functional structure and configurable items of the ground-based injection package manufacturing software, covering functions such as CAN bus connection, injection mode selection, injection package manufacturing, and injection process control, providing support for the specific implementation of this invention in the project.

[0067] This solution has undergone hundreds of on-orbit verifications on multiple remote sensing satellites, covering three scenarios: differential uploading updates, full uploading recovery, and version migration synchronization. The uploading process is highly efficient and stable, improving the utilization rate of telemetry and control resources by 60% and achieving a reconstruction success rate of 99%. Through the division of labor and collaboration among the initial version, official version, and test version, combined with the rapid reconstruction capability of differential uploading and the flexible synchronization mechanism of version migration, modifications to the satellite operation software can be verified and deployed on-orbit within a small number of telemetry and control orbits. This greatly reduces the difficulty of on-orbit reconstruction of the satellite operation software and provides strong support for its stable on-orbit operation.

Claims

1. An on-orbit reconfiguration and multi-version management system for space service software, characterized in that, The system includes a difference calculation module, a compression encoding and decoding module, a data receiving and verification module, and a multi-version storage management module; The difference calculation module is deployed on the ground. Based on the old and new versions of the satellite software executable files, it uses the BSDiff incremental update algorithm to calculate differences and generate program difference blocks. The compression and encoding / decoding module performs secondary compression on the uploaded program blocks on the ground and decompresses the compressed difference blocks on the satellite. The data receiving and verification module is deployed on the satellite. It receives the reconstructed data files according to the satellite-ground communication protocol, combines the data packets into a complete reconstructed file, combines the received difference blocks with the original version to construct a new program, and performs program verification. The multi-version storage management module is responsible for the storage management of multiple versions of programs on the satellite, data migration between versions, and selection of the startup version.

2. The on-orbit reconfiguration and multi-version management system for space service software according to claim 1, characterized in that, The operations performed in the difference calculation module include constructing an array of old file suffixes, searching for the longest match segment by segment in the new file, expanding the approximate match, and encapsulating the difference block.

3. The on-orbit reconfiguration and multi-version management system for space service software according to claim 2, characterized in that, Construction of old file suffix array: Treat the old and new versions of the Star Service software executable files as byte sequences, construct a lexicographically ordered suffix array for the old files, thereby realizing the binary matching and positioning of the new file substring in the old files; Longest Match Search in New File Segment by Segment: Traverse the new file, find the longest matching segment of the byte sequence based on the suffix array, eliminate redundant matches through the eight-byte difference filtering rule, and accurately define the effective matching interval; Approximate matching extension: The exact matching interval is extended bidirectionally, with a byte matching ratio of no less than 50% as a constraint, dividing the unmodified block and the source code modified block to form an independent approximate matching interval; Difference block encapsulation: Integrates matching and difference data, encapsulates difference blocks containing three areas: control flow, difference data, and additional data, and achieves accurate reconstruction from old files to new files through corresponding instructions.

4. The on-orbit reconfiguration and multi-version management system for space service software according to claim 3, characterized in that, The operations performed in the compression encoding / decoding module include Burrows-Wheeler transform, Move-to-Front encoding, Run-Length encoding, Huffman encoding, and on-board decompression.

5. The on-orbit reconfiguration and multi-version management system for space service software according to claim 4, characterized in that, Burrows-Wheeler Transform: Performs the Burrows-Wheeler transformation on the byte sequence of the program's difference block, sorting all cyclic shifts in the data stream to group similar characters together; Move-to-Front encoding: Performs Move-to-Front encoding on the output data of the Burrows-Wheeler transform, replacing the byte index and updating the list based on a 256-byte ordered table; Run-Length Encoding: Run-Length encoding is applied to Move-to-Front encoded output data, replacing consecutive repeating character sequences with combinations of characters and repetition counts; Huffman coding: Based on the frequency of byte occurrence in the Run-Length encoded output data, an optimal prefix coding tree is constructed, and long and short codes are allocated according to the frequency. Finally, a compressed difference block data stream is generated, which is called a compressed difference block. On-board decompression: After merging the complete compressed difference blocks on-board, multi-level decoding and Burrows-Wheeler inverse transformation are performed in reverse to restore the original program difference blocks without loss.

6. The on-orbit reconfiguration and multi-version management system for space service software according to claim 5, characterized in that, The operations performed in the data receiving and verification module include reconstructing process initiation and baseline file reading, data block packet reception and packet-by-packet verification, compressed difference block merging and decompression, difference decoding and new file construction, full-volume uploading mode processing, and program integrity and consistency verification.

7. The on-orbit reconfiguration and multi-version management system for space service software according to claim 6, characterized in that, Reconstruction process initiation and baseline file reading: After receiving the read command, the satellite enables the upload function, reads the specified version of the program data into the reconstruction buffer, records the program length, and establishes the difference upload baseline file; Data block packet reception and packet-by-packet verification: The satellite receives various types of data command packets from the ground uplink, performs CRC verification on each data packet, sorts and buffers the data and sends an acknowledgment if the verification passes, and reports and waits for the data to be retransmitted if there is an error. Combining and decompressing compressed difference blocks: After receiving all data packets, they are concatenated into complete compressed difference blocks according to their packet numbers. The compression encoding and decoding module is then called to decompress the blocks using the BZip2 algorithm, restoring the original program difference blocks. Difference decoding and new file construction: Based on the ADD and INSERT instructions in the difference block control flow area, the old data difference overlay and new data writing operations are completed respectively, and the new version program file is constructed by processing each instruction; Full upload mode processing: This backup mode is enabled for scenarios where the old program on the satellite is damaged and cannot be used as a baseline. The full program is compressed and uploaded. The satellite automatically recognizes the compression mark and skips the difference decoding process. Program integrity and consistency verification: Compare the CRC check value and valid length of the new program file. If the verification passes, write it to storage and read it back for verification. If the verification fails, report the error and wait for the ground to re-upload data.

8. The on-orbit reconfiguration and multi-version management system for space service software according to claim 7, characterized in that, The operations performed in the multi-version storage management module include startup version determination and program loading, refactoring program writing and critical information updating, startup version switching, and version migration.

9. The on-orbit reconfiguration and multi-version management system for space service software according to claim 8, characterized in that, Startup version determination and program loading: The satellite is powered on and the key version parameters of the three-mode redundancy storage are read. The startup version is determined by a two-out-of-three vote, the program is loaded and CRC verification is completed. In case of an error, it will fall back to the default startup version. Reconstructing program writing and updating key information: Write the new program that has passed the verification to the corresponding storage area and read it back for verification. Update the program length, CRC check value and startup status of this version in a three-modal redundancy manner. Startup version switching: Modify the on-board version number to be started through a three-mode redundancy method, update the startup configuration, and enable the device to load the specified version program the next time it is powered on; Version migration: In response to ground instructions, the source version program is completely copied to the target version storage area. Only the program content is copied, and the target version parameters are subsequently verified and updated by the ground.

10. The on-orbit reconfiguration and multi-version management system for space service software according to claim 8, characterized in that, The triple redundancy specifically means that each parameter is written to three storage devices.

Images