A method for running software on board a satellite

Abstract

This invention discloses a method for running spaceborne software, comprising: after on-orbit programming of the spaceborne software, compressing and solidifying the programmed spaceborne software into ROM; the functional components of the spaceborne software include three modules; the states of each module in ROM: the decompression module is in its original uncompressed state, and the spaceborne software system functional module and the compression module are in their compressed states; the compressed modules are marked with a compression identifier; after the spaceborne software starts running, it is determined whether the compression identifier exists; if it exists, the software in the spaceborne computer's RAM is the software moved from ROM for the first time, and the spaceborne software system functional module and the compression module are decompressed and run; after the spaceborne software is decompressed, if the compression identifier does not exist, the spaceborne software system functional module and the compression module have been decompressed, and the spaceborne software system functional module is run periodically. This invention reduces the storage space occupied and improves storage efficiency and economic benefits.

Description

Technical Field

[0001] This invention relates to the field of spaceborne computer software compression, and in particular to a method for running spaceborne software where the size of the software exceeds the read-only memory (ROM) limit after on-orbit programming. Background Technology

[0002] Due to limitations in cost, size, and power consumption, the ROM resources in onboard computers are finite, which imposes strict constraints on the size of onboard software. However, with the rapid increase in the diversity and complexity of onboard software functions, the code size of the onboard software is also constantly expanding. In particular, after on-orbit programming is performed during the onboard computer's operation due to functional expansion and code error correction, the size of the onboard software will further increase, potentially exceeding the capacity of the onboard computer's ROM. Therefore, the onboard software needs to be compressed before it can be stored in ROM. Summary of the Invention

[0003] The purpose of this invention is to provide a method for running onboard software, thereby increasing the maximum size of the onboard software that can be permanently stored without increasing the onboard computer's hardware memory.

[0004] To achieve the above objectives, the present invention is implemented through the following technical solution:

[0005] A method for running spaceborne software includes: Step S1, after the spaceborne software is programmed in orbit, the programmed spaceborne software is compressed and then stored in the ROM of the spaceborne computer. The functional components of the spaceborne software include: a decompression module, a spaceborne software system module, and a compression module. The states of the decompression module, the spaceborne software system module, and the compression module in the ROM are as follows: the decompression module is in its original uncompressed state, and the spaceborne software system module and the compression module are in their compressed state; the compressed spaceborne software system module and the compression module are marked with a compression identifier.

[0006] Step S2: After the onboard software starts running, it is determined whether the compression identifier exists. If it exists, the software in the RAM of the onboard computer is the software that is being moved from the ROM for the first time. The onboard software system function modules and the compression module are decompressed and then run.

[0007] Step S3: After the onboard software is decompressed, if the compression identifier does not exist, the onboard software system function module and the compression module have been decompressed, and the onboard software system function module is run periodically.

[0008] Optionally, the RAM is divided into two storage areas, one of which is the primary RAM and the other is the backup RAM; the ROM is divided into six storage areas, three of which are the primary ROM and the other three are the backup ROM.

[0009] Optionally, step S1 includes: step S11, dividing the code of the onboard software into the following three types: startup code, decompression code, and other code; when the storage capacity occupied by the onboard software is greater than the storage capacity of the ROM, the startup code and the decompression code are moved to the backup RAM without compression.

[0010] Step S12: Compress the other code and move it to the backup RAM.

[0011] Step S13: Perform cyclic redundancy check on the startup code, the decompression code, and the other compressed code to obtain the compressed cyclic redundancy check code rc0, and write the compressed cyclic redundancy check code rc0 into the startup code, the decompression code, and the other compressed code respectively, and write the compression identifier word into the other code.

[0012] Step S14: Select and solidify the uncompressed startup code, the uncompressed decompressed code, and the compressed other codes into one of the six storage areas of the ROM based on the ground injection data.

[0013] Optionally, step S12 includes: compressing the other code using the Huffman compression algorithm, wherein the step of compressing the other code using the Huffman compression algorithm includes:

[0014] Step S121: Count the number of times each character appears in the other codes.

[0015] Step S122: Based on the number of occurrences of each character obtained in step S121, establish the optimal binary code tree.

[0016] Step S123: Calculate the bit code and bit code length corresponding to each character based on the optimal binary coding tree.

[0017] Step S124: Compress the other codes according to bit encoding to obtain the compressed other codes.

[0018] Optionally, step S13 includes: step S131, performing cyclic redundancy check on the uncompressed startup code, the uncompressed decompressed code, and the compressed other code before solidification to obtain the compressed cyclic redundancy check code rc0.

[0019] Step S132: Unlock the hardware lock of the ROM to allow writing to the ROM.

[0020] Step S133: Write the compressed cyclic redundancy check code (crc0) into the uncompressed startup code, the uncompressed decompressed code, and the compressed other codes respectively, and write the compression identifier into the compressed other codes.

[0021] Optionally, step S14 includes: curing is performed by batch curing, and the number of batches to be cured each time is selected according to the above instructions.

[0022] When the storage capacity occupied by the onboard software in the RAM is less than the storage capacity of a single copy in the six storage areas divided by the ROM, the uncompressed startup code, the uncompressed decompressed code, and the compressed other codes are selected and solidified into one of the six storage areas of the ROM according to the ground injection data.

[0023] Optionally, step S1 further includes: Step S15, after the hardening is completed, the hardware lock of the ROM is closed, write protection is restored, and writing to the ROM is not allowed. Cyclic redundancy check (CRC) is performed again on the uncompressed boot code, the uncompressed decompressed code, and the compressed other code in the ROM to obtain the hardened CRC code. The compressed CRC code rc0 is compared with the hardened CRC code; if the comparison result is consistent, it indicates that the hardening is correct.

[0024] Optionally, step S2 includes: step S21, when the compression identifier exists, moving the compressed other code to the backup RAM.

[0025] Step S22: Read the bit encoding and bit encoding length information of each character in the compressed other codes.

[0026] Step S23: Establish the optimal binary code tree before compression based on the median encoding and bit encoding length information obtained in step S22.

[0027] Step S24: Decompress the other compressed codes according to the optimal binary coding tree in step S23, and move them to one of the three main ROMs according to the ground injection data.

[0028] Read the compressed cyclic redundancy check code rc0, and perform cyclic redundancy check on the startup code, the decompression code, and the other decompressed code to obtain the decompressed cyclic redundancy check code rc. If the decompressed cyclic redundancy check code rc is equal to the compressed cyclic redundancy check code rc0, then the decompression is correct, the compression identifier is cleared, and the onboard software is restarted; otherwise, the decompression is incorrect.

[0029] Optionally, step S2 further includes: before decompression begins, activating a watchdog timer and setting its period to N seconds, where 30 ≤ N ≤ 40. If the decompression time exceeds N seconds, or if the decompressed cyclic redundancy check (CRC) code is not equal to the compressed CRC0 code, decompression fails. After N seconds, the watchdog timer is reset, and the boot code, decompression code, and other compressed code in the ROM are re-processed. Preferably, N = 35, but this invention is not limited thereto.

[0030] Optionally, the read-only memory is an electrically erasable programmable read-only memory.

[0031] The present invention proposes a method for running onboard software, which compresses the code of onboard software without increasing the hardware memory of the onboard computer, increases the maximum size of the onboard software that can be permanently stored, reduces the amount of storage space occupied, effectively improves storage efficiency, saves space and maintenance costs, and improves economic benefits. Attached Figure Description

[0032] Figure 1 This is a flowchart of the onboard software operation provided in an embodiment of the present invention;

[0033] Figure 2 This is a schematic diagram of the onboard software structure provided in an embodiment of the present invention;

[0034] Figure 3 This is a flowchart of the onboard software compression and solidification process provided in an embodiment of the present invention;

[0035] Figure 4 A flowchart illustrating the implementation of the Huffman compression algorithm according to an embodiment of the present invention;

[0036] Figure 5 This is a schematic diagram of the compressed data structure provided in an embodiment of the present invention;

[0037] Figure 6 This is a flowchart of decompression provided in an embodiment of the present invention. Detailed Implementation

[0038] The following detailed description, in conjunction with the accompanying drawings and specific embodiments, provides a further detailed explanation of the onboard software operation method proposed in this invention. The advantages and features of this invention will become clearer from the following description. It should be noted that the accompanying drawings are in a very simplified form and use non-precise proportions, intended only to facilitate and clearly illustrate the embodiments of this invention. Please refer to the accompanying drawings to make the objectives, features, and advantages of this invention more apparent and understandable. It should be understood that the structures, proportions, sizes, etc., depicted in the accompanying drawings are only for illustrative purposes to aid those skilled in the art and are not intended to limit the implementation conditions of this invention. Therefore, they have no substantial technical significance. Any modifications to the structure, changes in proportions, or adjustments to the size, without affecting the effects and objectives achieved by this invention, should still fall within the scope of the technical content disclosed in this invention.

[0039] like Figure 1 As shown, the onboard software operation method in this embodiment includes:

[0040] Step S1: After the on-orbit software is programmed, the programmed on-orbit software is compressed and then stored in the ROM of the on-orbit computer. The functional components of the on-orbit software include: a decompression module, an on-orbit software system module, and a compression module. The states of the decompression module, the on-orbit software system module, and the compression module in the ROM are as follows: the decompression module is in its original uncompressed state, and the on-orbit software system module and the compression module are in their compressed state; the compressed on-orbit software system module and the compression module are marked with a compression identifier.

[0041] Step S2: After the onboard software starts running, it is determined whether the compression identifier flg (0xfaceface, 0x55aa55aa) exists. If it exists, the software in the random access memory (RAM) of the onboard computer is the software that was moved from the ROM for the first time. The onboard software system functional modules and the compression module are decompressed and then run.

[0042] Step S3: After the onboard software is decompressed, if the compression identifier flg does not exist, the onboard software system function module and the compression module have been decompressed, and the onboard software system function module is run periodically.

[0043] This embodiment provides a method for running spaceborne software. It designs the decompression module, compression module, and spaceborne software system function module into a complete spaceborne software, achieving the goal of increasing the maximum size of the executable spaceborne software without increasing the spaceborne computer's hardware storage. This method eliminates the need to upload compression and decompression code, and features small data upload volume, security, and reliability. Conventional spaceborne software does not include compression and decompression modules; therefore, compression requires additional compression and decompression code. This invention designs the decompression module, compression module, and spaceborne software system function module into a complete spaceborne software, eliminating the need for additional compression and decompression code.

[0044] The structure of the onboard software is as follows: Figure 2 As shown, the onboard software structure is divided into three parts: the first part is the uncompressed segment (decompression function module), the second part is the compressed segment (onboard software system function module + compression function module), and the third part is the shared data space. The uncompressed segment is divided into: code segment.text, read-only data segment.rodata, data segment.data, and initial data segment.idata. The compressed segment is also divided into: code segment.text, read-only data segment.rodata, data segment.data, and initial data segment.idata. The shared data space includes: uninitialized global variable area.bss, heap area, and stack area.

[0045] Typically, the random access memory (RAM) has a storage capacity of, for example, 4MB. The first 2MB of the RAM is designated as primary RAM, and the last 2MB is designated as backup RAM. The backup RAM is a designated unused free RAM area.

[0046] Compression curing process as follows Figure 3 As shown, in this embodiment, step S1 includes:

[0047] Step S11: Divide the code of the onboard software into the following three types: startup code, decompression code, and other code; when the storage capacity occupied by the onboard software is greater than the storage capacity of the ROM, move the startup code and the decompression code to the backup RAM without compression.

[0048] Step S12: Compress the other code and move it to the backup RAM.

[0049] In this embodiment, step S12 includes: compressing the other code using the Huffman compression algorithm. The Huffman compression algorithm is a compression algorithm based on a greedy strategy. The basic idea is to use fewer bits to encode characters with high frequency and more bits to encode characters with low frequency, so that the total encoded length is less than the actual total character length, achieving the purpose of lossless data compression.

[0050] Compression and solidification process: The startup code and decompressed code are moved to the backup RAM area without compression. The backup RAM is a designated unused free RAM area; other code is compressed and moved to the backup RAM area; the uncompressed code and the compressed code are solidified into the ROM.

[0051] like Figure 4 As shown, the Huffman compression algorithm compresses the other code by including the following steps:

[0052] Step S121: Count the number of times each character appears in the other codes.

[0053] Step S122: Based on the number of occurrences of each character (0-255) obtained in step S121, establish the optimal binary code tree.

[0054] Step S123: Calculate the bit code and bit code length corresponding to each character based on the optimal binary coding tree.

[0055] Step S124: Compress the other codes according to bit encoding to obtain the compressed other codes.

[0056] Specifically, for easier understanding of the data structure of the compressed code, please refer to [link / reference]. Figure 5 The data structure of the other compressed code includes, for example, an 8-byte compression identifier flg (0xfaceface, 0x55aa55aa) + a 4-byte compressed code burning identifier burn_flg (the high 1 byte of the original source code's crc0 + the low 3 bytes of the original source code's byte length len) + the compressed bit encoding of characters 0-255 + the bit encoding length of characters 0-255 + the compressed code, but this invention is not limited thereto.

[0057] Please continue to refer to this. Figure 3Step S13: Perform cyclic redundancy check on the startup code, the decompression code, and the other compressed code to obtain the compressed cyclic redundancy check code crc0. Write the compressed cyclic redundancy check code crc0 into the startup code, the decompression code, and the other compressed code respectively. Then write the compression identifier flg into the other code. For example, the compression identifier is 0xfaceface or 0x55aa55aa.

[0058] In this embodiment, step S13 includes:

[0059] Step S131: Before solidification, perform cyclic redundancy check on the uncompressed startup code, the uncompressed decompressed code, and the other compressed code to obtain the compressed cyclic redundancy check code rc0.

[0060] Step S132: Unlock the hardware lock of the ROM to allow writing to the ROM.

[0061] Step S133: Write the compressed cyclic redundancy check code (crc0) into the uncompressed startup code, the uncompressed decompressed code, and the compressed other codes respectively, and write the compression identifier into the compressed other codes.

[0062] Step S14: The uncompressed startup code, the uncompressed decompressed code, and the compressed other codes are selected and solidified into one of the six storage areas of the ROM based on the ground injection data. The ROM is divided into six storage areas, three of which are primary ROMs and the other three are backup ROMs. When the storage capacity occupied by the onboard software in the RAM is less than the storage capacity of a single storage area in the six storage areas of the ROM, the uncompressed startup code, the uncompressed decompressed code, and the compressed other codes are selected and solidified into one of the six storage areas of the ROM based on the ground injection data.

[0063] Step S15: After the hardening process is complete, the hardware lock of the ROM is disabled, write protection is restored, and writing to the ROM is not allowed. Cyclic redundancy check (CRC) is performed again on the uncompressed boot code, the uncompressed decompressed code, and the compressed other code in the ROM to obtain the hardened CRC code. The compressed CRC code rc0 is compared with the hardened CRC code. If the comparison result is consistent, it indicates that the hardening was successful.

[0064] For example, in this embodiment, the ROM is an EEPROM (Electrically Erasable Programmable Read-Only Memory) with a size of 3MB. The software uses a redundant storage mode of three primary copies + three backup copies, with each copy having a storage capacity of 512KB. After on-orbit programming, the onboard software in RAM occupies 535.86KB of storage space, exceeding the 512KB single-copy storage capacity allocated to the EEPROM. Therefore, it must be compressed before being stored in the EEPROM. After compression, the onboard software occupies 424.29KB of storage space, which is less than the 512KB single-copy storage capacity allocated to the EEPROM, allowing it to be stored in the EEPROM. The EEPROM is stored in copies, one copy at a time, with the number of copies stored each time selected according to the input command. The EEPROM has write protection. Before storage, the hardware lock of the EEPROM is unlocked, allowing writing to the EEPROM. After storage, the hardware lock is unlocked, restoring write protection and disallowing writing to the EEPROM. Before the code is cured, the CRC checksum of the code to be cured is calculated. After the curing is completed, the CRC checksum of the cured code in the EEPROM is calculated again. If the two are consistent, it indicates that the curing is correct.

[0065] Please continue to refer to this. Figure 1 Step S2: After the onboard software starts running, it is determined whether the compression identifier flg (0xfaceface, 0x55aa55aa) exists. If it exists, the software in the RAM of the onboard computer is the software that was moved from the ROM for the first time. The onboard software system function modules and the compression module are decompressed and then run.

[0066] In this embodiment, decompression is the reverse process of compression, and the decompression process is as follows: Figure 6 As shown, step S2 includes:

[0067] Step S21: When the compressed identifier exists, move the compressed other code to the backup RAM.

[0068] Step S22: Read the bit encoding and bit encoding length information of each character in the compressed other codes.

[0069] Step S23: Establish the optimal binary code tree before compression based on the median encoding and bit encoding length information obtained in step S22.

[0070] Step S24: Decompress the other compressed codes according to the optimal binary coding tree in step S23, and select one of the three main ROMs to be moved to according to the ground injection data.

[0071] Read the compressed cyclic redundancy check code rc0, and perform cyclic redundancy check on the startup code, the decompression code, and the other decompressed code to obtain the decompressed cyclic redundancy check code rc. If the decompressed cyclic redundancy check code rc is equal to the compressed cyclic redundancy check code rc0, then the decompression is correct, the compression identifier is cleared, and the onboard software is restarted; otherwise, the decompression is incorrect.

[0072] In this embodiment, step S2 further includes: before decompression begins, activating a watchdog timer and setting its period to N seconds, where 30 ≤ N ≤ 40. If the decompression time exceeds N seconds, and if the decompressed cyclic redundancy check (CRC) code is not equal to the compressed CRC0, then decompression fails. After N seconds, the watchdog timer is reset, and the boot code, decompression code, and other compressed code in the ROM are re-processed. Preferably, N equals 35, but this invention is not limited thereto.

[0073] In summary, this embodiment discloses a method for running onboard software. After onboard software is programmed in orbit, it is compressed in orbit and then solidified into ROM: the startup code and decompression code are moved uncompressed to the backup RAM area, which is a designated unused free RAM area; then the remaining code is compressed and moved to the backup RAM area; finally, the uncompressed code plus the compressed code is solidified into ROM. After the onboard computer is powered on again or cold-reset, the compression identifier exists, the decompression function module is run to decompress the code to be decompressed, the compression identifier is cleared, and the onboard software is restarted. At this time, the compression identifier does not exist, and the onboard software system function module is run periodically. This embodiment designs the decompression function module, compression function module, and onboard software system function module into a complete onboard software, without the need to upload compression and decompression code, and has the characteristics of small data upload volume, security, and reliability.

[0074] Although the present invention has been described in detail through the preferred embodiments above, it should be understood that the above description should not be considered as a limitation of the present invention. Various modifications and substitutions to the present invention will be apparent to those skilled in the art after reading the above description. Therefore, the scope of protection of the present invention should be defined by the appended claims.

Claims

1. A method for running spaceborne software, characterized in that, include: Step S1: After the on-orbit software is programmed, the programmed on-orbit software is compressed and then solidified into the ROM of the on-orbit computer. The onboard software comprises: a decompression module, an onboard software system module, and a compression module. The states of the decompression module, the onboard software system module, and the compression module in the ROM are as follows: the decompression module is in its original uncompressed state, and the onboard software system module and the compression module are in their compressed states; the compressed onboard software system module and the compression module are marked with a compression identifier. Step S2: After the onboard software starts running, it is determined whether the compression identifier exists. If it exists, the software in the RAM of the onboard computer is the software that is being moved from the ROM for the first time. The onboard software system function module and the compression function module are decompressed and then run. Step S3: After the onboard software is decompressed, if the compression identifier does not exist, the onboard software system function module and the compression function module have been decompressed, and the onboard software system function module is run periodically.

2. The onboard software operation method according to claim 1, characterized in that, The RAM is divided into two storage areas, one of which is the primary RAM and the other is the backup RAM; the ROM is divided into six storage areas, three of which are the primary ROM and the other three are the backup ROM.

3. The onboard software operation method according to claim 2, characterized in that, Step S1 includes: Step S11: Divide the code of the onboard software into the following three types: startup code, decompression code, and other code; when the storage capacity occupied by the onboard software is greater than the storage capacity of the ROM, move the startup code and the decompression code to the backup RAM without compression. Step S12: Compress the other code and move it to the backup RAM; Step S13: Perform cyclic redundancy check on the startup code, the decompression code, and the other compressed code to obtain the compressed cyclic redundancy check code crc0, and write the compressed cyclic redundancy check code crc0 into the startup code, the decompression code, and the other compressed code respectively, and write the compression identifier word into the other code. Step S14: Select and solidify the uncompressed startup code, the uncompressed decompressed code, and the compressed other codes into one of the six storage areas of the ROM based on the ground injection data.

4. The onboard software operation method according to claim 3, characterized in that, Step S12 includes: compressing the other code using the Huffman compression algorithm, wherein the step of compressing the other code using the Huffman compression algorithm includes: Step S121: Count the number of times each character appears in the other codes; Step S122: Based on the number of occurrences of each character obtained in step S121, establish the optimal binary coding tree; Step S123: Calculate the bit code and bit code length corresponding to each character based on the optimal binary coding tree; Step S124: Compress the other codes according to bit encoding to obtain the compressed other codes.

5. The onboard software operation method according to claim 4, characterized in that, Step S13 includes: Step S131: Before solidification, perform cyclic redundancy check on the uncompressed startup code, the uncompressed decompressed code, and the other compressed code to obtain the compressed cyclic redundancy check code rc0. Step S132: Unlock the hardware lock of the ROM to allow writing to the ROM; Step S133: Write the compressed cyclic redundancy check code (crc0) into the uncompressed startup code, the uncompressed decompressed code, and the compressed other codes respectively, and write the compression identifier into the compressed other codes.

6. The onboard software operation method according to claim 5, characterized in that, Step S14 includes: curing is carried out by part-by-part curing, and the number of parts to be cured each time is selected according to the injection instruction; When the storage capacity occupied by the onboard software in the RAM is less than the storage capacity of a single copy in the six storage areas divided by the ROM, the uncompressed startup code, the uncompressed decompressed code, and the compressed other codes are selected and solidified into one of the six storage areas of the ROM according to the ground injection data.

7. The onboard software operation method according to claim 6, characterized in that, Step S1 further includes: Step S15: After the hardening is completed, the hardware lock of the ROM is turned off, write protection is restored, and writing to the ROM is not allowed. Cyclic redundancy check is performed again on the uncompressed boot code, the uncompressed decompressed code, and the other compressed code in the ROM to obtain the solidified cyclic redundancy check code. The compressed cyclic redundancy check code rc0 is compared with the solidified cyclic redundancy check code. If the comparison result is consistent, it indicates that the solidification is correct.

8. The onboard software operation method according to claim 7, characterized in that, Step S2 includes: Step S21: When the compression identifier exists, move the compressed other code to the backup RAM; Step S22: Read the bit encoding and bit encoding length information of each character in the compressed other codes; Step S23: Establish the optimal binary code tree before compression based on the median encoding and bit encoding length information obtained in step S22; Step S24: Decompress the other compressed codes according to the optimal binary coding tree in step S23, and select one of the three main ROMs to be moved to according to the ground injection data; Read the compressed cyclic redundancy check code rc0, and perform cyclic redundancy check on the startup code, the decompression code, and the other decompressed code to obtain the decompressed cyclic redundancy check code rc. If the decompressed cyclic redundancy check code rc is equal to the compressed cyclic redundancy check code rc0, then the decompression is correct, the compression identifier is cleared, and the onboard software is restarted; otherwise, the decompression is incorrect.

9. The onboard software operation method according to claim 8, characterized in that, Step S2 further includes: Before decompression begins, a watchdog timer is activated, and its period is set to N seconds, where 30 ≤ N ≤ 40. If the decompression time exceeds N seconds, and the decompressed cyclic redundancy check (CRC) code is not equal to the compressed CRC0 code, then decompression fails. After N seconds, the watchdog timer is reset, and the boot code, decompression code, and other compressed code in the ROM are moved again.

10. The onboard software operation method according to claim 1, characterized in that, The ROM is an electrically erasable programmable read-only memory.

Images