Spaceborne device firmware streaming compression upgrade method for commercial space

Abstract

This invention provides a streaming compression upgrade method for onboard equipment firmware for commercial aerospace, relating to the field of spacecraft on-orbit maintenance technology. The ground-based system uses the DEFLATE algorithm to compress the firmware, extracting an identifier header including the magic number and original size, and segmenting the compressed stream into independent data packets according to link capacity. The onboard system receives data using a pre-set input circular buffer and a circular history buffer, driving an interruptible and recoverable decompression state machine for streaming decoding. Decoded bytes are synchronously written to non-volatile memory and the circular history buffer. When input is exhausted, the entire running state is saved and paused; it is precisely restored upon the arrival of new data. The advantages of this invention are: total RAM usage is less than 40KB, enabling simultaneous reception, decompression, and writing, significantly shortening narrowband link transmission time, and effectively solving the upgrade challenges of limited memory, short transit windows, and easy link interruptions for commercial low-Earth orbit small satellites.

Description

Technical Field

[0001] This invention belongs to the field of spacecraft on-orbit maintenance and onboard embedded device firmware upgrade, and in particular relates to a streaming compression upgrade method for onboard device firmware for commercial spaceflight. Background Technology

[0002] With the rapid development of the commercial space industry, the large-scale deployment of low-Earth orbit (LEO) small satellite constellations has placed higher demands on on-orbit firmware upgrades for onboard equipment. Existing firmware upgrade technologies mainly include direct transmission of the original binary file, one-time decompression on-board after overall compression on the ground, and full-data caching in segments. However, these existing technologies have significant problems when adapted to commercial LEO small satellites: First, commercial small satellites generally use UHF or S-band narrowband telemetry and control links, with a single transmission payload of only a few hundred bytes. Transmitting raw firmware in the tens of megabytes range takes an extremely long time, making it difficult to complete a full transmission within the short single-round transit window of 5 to 15 minutes, resulting in extremely high link resource occupancy.

[0003] Secondly, existing compression upgrade solutions mostly rely on large-capacity onboard memory to cache the entire compressed stream or all packetized data at once. However, commercial satellite onboard computers mostly use industrial-grade microcontrollers with only a few hundred KB of on-chip RAM. Due to hardware cost and power consumption limitations, they cannot provide the large-capacity cache space required by traditional decompression architectures.

[0004] Secondly, existing solutions lack streaming data processing and operational status snapshot mechanisms. When the satellite-to-ground link is interrupted due to obstruction or interference, the system often cannot retain the decompression progress and needs to retransmit and decompress from scratch, resulting in a low success rate for upgrades in poor channel environments. Furthermore, the existing architecture struggles to flexibly adjust data packet specifications based on real-time link quality, leading to poor engineering adaptability.

[0005] Therefore, there is an urgent need in this field for a firmware upgrade method that overcomes the limitations of onboard memory, supports streaming while decompressing, and has the ability to resume interrupted transmission, in order to meet the low-cost, high-reliability on-orbit maintenance requirements of commercial aerospace. Summary of the Invention

[0006] In view of this, the present invention aims to propose a streaming compression upgrade method for spaceborne equipment firmware for commercial aerospace, in order to solve the problems existing in at least one of the above-mentioned prior art solutions.

[0007] To achieve the above objectives, the technical solution of the present invention is implemented as follows: This invention provides a method for streaming compression upgrade of firmware for spaceborne equipment in commercial aerospace, including a ground compression and subpackaging stage and an on-board streaming decompression and upgrade stage; The ground compression subcontracting stage includes the following steps: S1: Obtain the original firmware binary file to be upgraded, and use the standard DEFLATE algorithm to perform lossless compression on the original firmware binary file to generate a compressed firmware file; S2: Extract the file identifier header of the compressed firmware file. The file identifier header includes at least a magic number field and an original firmware binary file size field. Save the file identifier header as a header file. S3: Divide the compressed firmware file according to the preset target data packet size to generate multiple independent data packet files, wherein the data packet files only include pure compressed stream segments; The on-board streaming decompression and upgrade stage includes the following steps: S4: The on-board decompression system receives the file identifier header, verifies the magic number field to confirm the file's legality, and then extracts the original firmware binary file size field; the on-board decompression system uses a pre-configured input circular buffer and a circular history buffer for decompression processing; S5: The on-board decompression system receives the data packet files sequentially and writes the pure compressed stream segments in the data packet files into the input circular buffer; S6: Call the decompression processing function to drive the decompression state machine to read bitstream data from the input circular buffer for decoding; S7: When the decompression state machine decodes and outputs a valid byte, the valid byte is synchronously written to the external non-volatile memory and the circular history buffer; S8: When the input circular buffer is exhausted, the decompression state machine pauses operation and saves the current running state completely, waiting for a new data packet to arrive before resuming operation, until the total number of bytes of decompression output reaches the size of the original firmware binary file.

[0008] Furthermore, in step S2, the file identifier header is 8 bytes long; the magic number field is 4 bytes long and is set to 0x44454C46; the original firmware binary file size field is 4 bytes long and is a 32-bit unsigned integer.

[0009] Furthermore, in step S3, the target data packet size is configured based on the single transmission capacity of the satellite-to-ground link and the size of the on-board receiving buffer, with a value range including 64 bytes to 4096 bytes; the data packet file is named and encoded with sequence numbers according to the transmission order.

[0010] Furthermore, in step S4, the size of the input circular buffer is set to 4KB, and a circular queue structure is used to implement it; In step S5, the on-board decompression system writes the received data packet payload into the current write pointer position of the input circular buffer and updates the write pointer. In step S6, the decompression state machine reads bitstream data from the current read pointer position of the input circular buffer and updates the read pointer; In step S8, when the read pointer and the write pointer address coincide, it is determined that the input circular buffer is exhausted.

[0011] Furthermore, in step S4, the size of the circular history buffer is set to 32KB and allocated in the on-board RAM; In step S7, the valid byte is written to the current write pointer position of the circular history buffer, and the write pointer is then incremented cyclically by a modulus of 32KB. When the decompression state machine decodes the distance / length pair, the source data address is calculated based on the current write pointer and the matching distance, and historical data of a specified length is continuously read from the source data address for matching and copying.

[0012] Furthermore, the expression for calculating the source data address is as follows: Source address = (write pointer - matching distance) mod 32768; If the reading process crosses the end boundary of the circular history buffer, segmented reading is automatically performed. First, the reading reaches the end of the circular history buffer, and then the remaining bytes are read from the beginning of the circular history buffer.

[0013] Furthermore, in step S8, the decompression state machine includes three core operating phases: phase 0 is the block header parsing phase, phase 1 is the data decoding phase, and phase 2 is the dynamic Huffman tree construction phase. The fully saved current running state includes: the Huffman tree structure currently being decoded, the code length sequence padding position, the number of bytes remaining for matching and copying, the bit buffer data, and the current stage identifier; The step of waiting for a new data packet to arrive before resuming operation includes: when a new data packet arrives, the decompression state machine resumes from the previously saved running state and continues to execute the decoding process.

[0014] Furthermore, it also includes a breakpoint resume step: the onboard decompression system maintains and records in real time the sequence number of the largest consecutive data packet that has been successfully decoded and completely written to the external non-volatile memory; When the satellite-to-ground link is interrupted, the ground station will query the sequence number of the largest consecutive data packet via telemetry commands when the satellite passes overhead again. The ground station continues transmission starting from the next data packet corresponding to the largest consecutive data packet sequence number; After receiving subsequent data packets, the on-board decompression system seamlessly resumes operation from the running state saved when the link was interrupted.

[0015] Furthermore, in step S7, the writing to the external non-volatile memory is implemented using a callback function mechanism; The decompression processing function includes configuring the maximum number of output bytes per call, and returning immediately when the number of output bytes reaches the threshold or the input circular buffer is exhausted.

[0016] Secondly, based on the same concept, the present invention also provides a satellite-borne equipment firmware streaming compression upgrade system for commercial aerospace, including a ground compression system and an on-board decompression system; the ground compression system is used to execute the ground compression subpackaging stage steps; the on-board decompression system includes an on-board embedded processor, an external non-volatile Flash memory, and a streaming decompression software module; the streaming decompression software module has built-in an input circular buffer, an interruptible and recoverable decompression state machine, a circular history buffer, and a Flash write controller, used to execute the on-board streaming decompression upgrade stage steps.

[0017] Compared with existing technologies, the firmware streaming compression upgrade method for spaceborne equipment for commercial aerospace described in this invention has the following advantages: (1) Due to the adoption of the ground standard DEFLATE lossless compression and pure compressed stream packetization technology, the typical compression rate for satellite binary firmware can reach 60% to 80%. Under the narrowband satellite-to-ground link of 10kbps, the transmission time of the original firmware of tens of MB can be shortened from several hours / days to 1 to 2 satellite overpasses, so that the firmware upgrade can be completed within a limited single-circle visible arc of a few minutes, which significantly improves the utilization rate of satellite-to-ground link resources.

[0018] (2) Due to the adoption of a fixed-size input circular buffer (4KB) and a circular history buffer (32KB) collaborative architecture, the on-board decompression process does not require caching of the complete compressed file, and the total RAM usage during operation is strictly controlled within 40KB. This directly overcomes the shortcomings of commercial small satellites, which generally use industrial-grade MCUs (with only a few hundred KB of on-chip RAM), and cannot run traditional one-time decompression schemes. It eliminates the need for additional external SRAM expansion or processor upgrades, achieving perfect adaptation to low-cost on-board computing platforms.

[0019] (3) Since the decompression state machine and the dual-ring buffer adopt a streaming data interaction mechanism, the on-board decompression system can start the decoding process immediately after receiving the first data packet, and decouple the link receiving rate and the CPU decompression rate through the read and write pointers of the input buffer. This eliminates the need for the on-board system to reserve a large amount of storage space to cache the full packet data, greatly reducing the dependence on the on-board Flash pre-allocated space, and supporting multi-task concurrent scheduling without triggering the embedded system watchdog timeout.

[0020] (4) Because the decompression state machine is an interruptible snapshot architecture, it can completely save all intermediate variables such as bit buffer, Huffman tree structure, LZ77 matching progress and stage identifier when the input buffer is exhausted or the link is interrupted; combined with the telemetry confirmation mechanism of the maximum consecutive successful data packet sequence number, the ground can seamlessly resume transmission from the breakpoint sequence number, and the decompression state machine is accurately restored to the paused position. It completely avoids the defects of traditional solutions that require retransmission or re-decompression after interruption, and is particularly suitable for the transmission characteristics of low-orbit satellites frequently passing overhead and links being easily blocked.

[0021] (5) Since the data packet segmentation granularity supports software configuration within the range of 64 to 4096 bytes, the ground can dynamically adjust the packet size according to the UHF / S band link quality, bit error rate, and telemetry and control system, balancing transmission efficiency and retransmission cost. At the same time, Flash writing adopts a callback function mechanism, and the decompression core logic is not bound to a specific memory driver, which can flexibly adapt to different media such as on-chip Flash, SPI Flash, QSPI Flash, or SD card. This allows the present invention to be ported to various spaceborne devices across platforms without modifying the core algorithm code.

[0022] (6) This invention is based entirely on the software-level reconstruction of the firmware upgrade process. The ground uses the standard zlib ecosystem toolchain, and the satellite is implemented based on a lightweight C language state machine, without the need to introduce dedicated compression chips, FPGAs, or radiation-resistant large-capacity memory. Under the premise of ensuring high compression ratio and high reliability of transmission, it achieves 100% reuse of satellite hardware resources, significantly reduces the single-satellite BOM cost and system integration complexity, and provides a standardized and mass-producible technical foundation for the large-scale on-orbit maintenance of low-Earth orbit commercial constellations. Attached Figure Description

[0023] The accompanying drawings, which form part of this invention, are used to provide a further understanding of the invention. The illustrative embodiments of the invention and their descriptions are used to explain the invention and do not constitute an undue limitation of the invention. In the drawings: Figure 1 This is a schematic diagram of the overall architecture and process described in the embodiments of the present invention; Figure 2 This is a schematic diagram of the ground compression sub-packaging process described in an embodiment of the present invention; Figure 3 This is a schematic diagram of the state transition of the on-board decompression state machine according to an embodiment of the present invention; Figure 4 This is a schematic diagram illustrating the operation of the circular history buffer as described in an embodiment of the present invention; Figure 5 This is a schematic diagram illustrating the data packet and its naming rules as described in an embodiment of the present invention; Figure 6 This is a schematic diagram illustrating the management of the input circular buffer as described in an embodiment of the present invention. Detailed Implementation

[0024] It should be noted that, unless otherwise specified, the embodiments and features described in the present invention can be combined with each other.

[0025] In the description of this invention, it should be understood that the terms "center," "longitudinal," "lateral," "upper," "lower," "front," "rear," "left," "right," "vertical," "horizontal," "top," "bottom," "inner," and "outer," etc., indicating orientations or positional relationships based on the orientations or positional relationships shown in the accompanying drawings, are only for the convenience of describing the invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of the invention. Furthermore, the terms "first," "second," etc., are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Thus, a feature defined with "first," "second," etc., may explicitly or implicitly include one or more of that feature. In the description of this invention, unless otherwise stated, "a plurality of" means two or more.

[0026] In the description of this invention, it should be noted that, unless otherwise explicitly specified and limited, the terms "installation," "connection," and "linking" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral connection; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; and they can refer to the internal connection of two components. Those skilled in the art will understand the specific meaning of the above terms in this invention based on the specific circumstances.

[0027] The present invention will now be described in detail with reference to the accompanying drawings and embodiments.

[0028] like Figures 1 to 6 As shown, this is a streaming compression upgrade method for spaceborne equipment firmware for commercial aerospace applications. Figure 1As shown, the overall architecture and process of the system consist of three parts: a ground compression system, a satellite-to-ground link, and an onboard decompression system. The ground compression system performs lossless DEFLATE compression on the original firmware file to be upgraded, generating a hybrid structure including a magic number identifier, the size of the original firmware binary file, and the compressed data stream. The compressed stream is then segmented according to preset values, separating the file identifier header and the pure compressed data packet sequence. This file sequence is transparently transmitted via the satellite-to-ground link, which only acts as a physical channel and does not handle compression or decompression logic. The onboard decompression system buffers uplink data packets through an input circular buffer. The decompression state machine extracts the bit stream from this buffer for real-time decoding. During decoding, the decompression state machine maintains bidirectional data interaction with a 32KB circular history buffer to meet the LZ77 algorithm's read / write requirements for the historical sliding window. Finally, the decompressed valid bytes are written to the external Flash memory in real-time via the Flash controller, achieving seamless integration between high-compression-ratio preprocessing on the ground and low-memory streaming decompression onboard. It should be further explained that regarding the bidirectional data interaction between the decompression state machine and the circular history buffer, on the one hand, the decompression state machine continuously writes each decoded output byte into the buffer to continuously update the 32KB sliding window content; on the other hand, when the decompression state machine decodes the LZ77 distance / length pair, it reads historical data from the buffer to complete the matching and copying, ensuring the continuity and correctness of streaming decompression.

[0029] The specific embodiments of the present invention are as follows: 1. System Composition (1) Ground compression system: The ground compression system is used to perform the steps of the ground compression and packetization stage. It consists of a computer, a compression module, and a packetization module. The compression module is developed based on Qt and adopts the standard DEFLATE lossless compression algorithm. The packetization module is used to divide the compressed DEFLATE stream according to the configured data packet size and generate independent sequence number data packet files.

[0030] (2) On-board decompression system: including on-board embedded processor, external non-volatile Flash memory, and streaming decompression software module; the streaming decompression software module has a built-in input ring buffer, an interruptible and recoverable decompression state machine, a ring history buffer and a Flash write controller.

[0031] (3) Satellite-Ground Link: As a transparent transmission channel, it is only responsible for sending the header files and data packets generated on the ground to the onboard equipment to be upgraded in sequence, and does not participate in the core logic processing of compression, packet splitting, and decompression. It should be further explained that the onboard equipment to be upgraded refers to the central processing unit (MCU) of the satellite payload equipment or the central processing unit (MCU) of the satellite platform equipment. The satellite platform equipment mainly includes attitude control system, satellite computer, propulsion system, energy system, telemetry and control system, and thermal control system, while the payload equipment mainly includes communication payload, navigation payload, remote sensing payload, AI payload, etc.

[0032] 2. For example Figure 2 As shown, ground compression subcontracting stage When releasing firmware to be upgraded, the ground processing procedure is as follows: The first step is to obtain the original firmware binary file (.bin format) to be upgraded, and then perform lossless compression on the original firmware binary file using the standard DEFLATE algorithm to generate a complete compressed data stream. The DEFLATE algorithm consists of two core stages: the first is the LZ77 compression stage, which searches for duplicate strings in the processed data using a 32KB sliding window and outputs distance / length pairs or literals to form a symbol sequence; the second is the Huffman coding stage, which constructs a Huffman tree by statistically analyzing the frequency of symbol occurrences and replaces the original symbols with variable-length codes to achieve secondary lossless compression.

[0033] The second step is to extract the file identifier header of the compressed firmware file. The file identifier header includes at least a magic number field and a field for the size of the original firmware binary file. Specifically, the file identifier header is 8 bytes long; the magic number field is 4 bytes long and is set to 0x44454C46; the field for the size of the original firmware binary file is 4 bytes long and is a 32-bit unsigned integer. The file structure of the compressed firmware file is shown in Table 1. Table 1 The third step involves dividing the compressed firmware file into multiple independent data packet files according to the preset target data packet size. Each data packet file contains only a pure compressed stream segment. The target data packet size is configured based on the single transmission capacity of the satellite-to-ground link and the size of the onboard receiver buffer, with values ​​ranging from 64 bytes to 4096 bytes. The data packet files are named using sequence numbering according to the transmission order. Specifically, the target data packet size is configured through the compression software based on the single transmission capacity of the satellite-to-ground link and the size of the onboard receiver buffer (optional values ​​include 256 bytes, 512 bytes, 1024 bytes, etc.). The compression software divides the DEFLATE compressed stream into data packet files of corresponding sizes according to the configured data packet size. Each data packet file is a pure compressed stream segment without any additional header information. Figure 5As shown, the 8-byte file identifier header (magic number + original size) in the compressed firmware file is saved separately as a header.bin header file; the segmented data packet files are numbered and named according to the transmission order, such as packet_0001.bin, packet_0002.bin, etc., to form a complete transmission packet sequence.

[0034] 3. Upgraded stage of star-borne flow decompression The first step is for the onboard decompression system to receive the file identifier header, verify the magic number field to confirm the file's legality, and then extract the original firmware binary file size field. The onboard decompression system then uses a pre-configured input circular buffer and a circular history buffer for decompression processing. The second step is that the on-board decompression system receives data packet files in sequence and writes the pure compressed stream segments in the data packet files into the input circular buffer. The third step is to call the decompression processing function, which drives the decompression state machine to read bitstream data from the input circular buffer for decoding; Fourth step: When the decompression state machine decodes and outputs valid bytes, the valid bytes are synchronously written to the external non-volatile memory and the circular history buffer. Fifth, when the input circular buffer is exhausted, the decompression state machine pauses operation and saves the current running state completely, waiting for new data packets to arrive before resuming operation, until the total number of bytes of decompressed output reaches the size of the original firmware binary file.

[0035] 4. Streaming decompression software module The streaming decompression software module is the core of this invention, focusing on three main objectives: low memory usage, streaming processing, and interruptible state recovery. This module includes an input circular buffer, an interruptible decompression state machine, a circular history buffer, and a Flash write controller, used to execute the steps of the onboard streaming decompression upgrade phase.

[0036] 4.1 such as Figure 6 As shown, the input circular buffer To accommodate input data packets of any size, the onboard decompression system maintains a fixed-size circular buffer, typically configured to be 4KB, as an input buffer. This buffer is implemented using a circular queue structure. In the data reception interrupt service routine or main loop thread, the on-board decompression system writes the received data packet payload into the input circular buffer and updates the write pointer synchronously. The decompression state machine reads bitstream data from the input circular buffer and updates the read pointer synchronously. When the read pointer and write pointer addresses coincide, it is determined that the input buffer is exhausted. The decompression state machine immediately pauses and saves the current running state completely, waiting for a new data packet to arrive before resuming operation.

[0037] The input circular buffer eliminates the need for the onboard decompression system to know the total length of the compressed stream, allowing it to flexibly adapt to data packets of any size arriving in fragments. The buffer size is fixed and independent of the file size of the firmware to be upgraded. The data packet size can be configured arbitrarily within the range of 64 to 4096 bytes, as long as it does not exceed the total size of the input circular buffer.

[0038] Specifically, such as Figure 6 As shown, the data reception and decompression / reading mechanism based on a circular queue structure works as follows: When the system receives a new data packet, it extracts its payload and writes it to the current write pointer w position of the input buffer in_ring. The write pointer then increments cyclically by a modulus of 4096. When the decompression state machine needs to read bytes, it first checks if the read pointer r and write pointer w coincide. If they coincide, the buffer is empty, and the state machine immediately pauses decompression and waits for new data to arrive. If they do not coincide, bytes are read from the in_ring[r] position, and the read pointer r increments cyclically by the same modulus. The figure also shows the linear structure of the 4KB input buffer and the relative positions of the read and write pointers.

[0039] 4.2 such as Figure 3 As shown, the decompression state machine is interruptible and resumable. A DEFLATE compressed stream consists of a series of data blocks, each of which can be categorized into three types: uncompressed block, fixed Huffman block, and dynamic Huffman block. This invention implements segmented decoding of the DEFLATE compressed stream through a decompression state machine, which comprises three core operational phases: Phase 0: Block header parsing phase. Read a 1-bit final flag (used to identify whether it is the last data block of the compressed stream) and a 2-bit block type flag from the input bit stream, and jump to the corresponding processing branch according to the block type.

[0040] Phase 1: Data decoding phase, looping through the following operations: decode a symbol (literal or distance / length pair); if it is a literal in the range of 0 to 255, output the byte directly; if it is a distance / length pair, enter the matching copy state; if it is a block end symbol (256), return to phase 0 to prepare for processing the next data block.

[0041] Phase 2: Dynamic Huffman Tree Construction Phase. For dynamic Huffman blocks, the code length sequence is first read and the code length tree is constructed. Then, based on the code length tree, the literal / length tree and distance tree are generated by decoding. After the Huffman tree construction is completed, the process jumps to Phase 1 to perform data decoding.

[0042] It should be noted that, regarding the decompression state machine, any stage of operation can be paused immediately when there is insufficient input data, and the current running state is completely saved, that is, all intermediate running variables are saved, including the Huffman tree structure currently being decoded, the code length sequence padding position, the number of bytes remaining for matching and copying, bit buffer data, the current stage identifier, etc.; when a new data packet arrives and the decompression processing function is called again, the decompression state machine can be precisely restored from the last interrupted position and continue to execute the decoding process.

[0043] 4.3 Circular History Buffer and Matching Replication Mechanism The LZ77 decompression process requires referencing previously output historical data, completing the matching and copying through distance / length pairs. In the "distance / length pair," the distance represents the backtracking offset in bytes of the data to be matched within the historical buffer, and the length represents the number of bytes of matching data to be continuously copied. To support streaming writes to Flash while avoiding the impact of reading historical data from low-speed Flash on decompression efficiency, this invention allocates a fixed 32KB circular historical buffer in the onboard RAM to store the most recently decompressed bytes. The size of the circular historical buffer is exactly the same as the size of the DEFLATE standard sliding window, covering most matching scenarios of the LZ77 algorithm.

[0044] Whenever the decompression state machine decodes and outputs a valid byte (whether it is a literal or a byte generated by matching and copying), the byte is synchronously written to two target addresses: one is written to the external non-volatile Flash memory via the Flash write controller, and the other is written to the current write pointer position in the circular history buffer. The write pointer is then cyclically incremented in 32KB increments.

[0045] When the decompression state machine decodes and obtains the distance / length pair, the system calculates the source data address based on the current write pointer and the matching distance. The calculation formula is: source address = (write pointer - distance) mod 32768. Starting from this source address, the system continuously reads historical data of a specified length. If the reading process crosses the end boundary of the buffer, it automatically performs segmented reading, first reading to the end of the buffer, and then reading the remaining bytes from the beginning of the buffer to achieve seamless matching and copying.

[0046] The circular history buffer operates entirely in the on-chip RAM, avoiding reading historical data from low-speed Flash and ensuring decompression speed; the buffer size is fixed at 32KB, which is unrelated to the size of the firmware to be upgraded, thus minimizing the on-board RAM usage; the matching copy process is completely decoupled from the Flash writing process, supporting matching copies of any length without affecting the core process of streaming Flash writing.

[0047] Specifically, such as Figure 4As shown, the data writing mechanism and boundary handling logic during LZ77 matching and copying are as follows: When the decompression state machine outputs a valid byte X, it is first written to the external Flash, and then synchronously written to the current write pointer w position of the circular history buffer. The write pointer then increments cyclically by a modulus of 32768. The figure also shows the linear structure of the 32KB buffer in memory and the cyclic movement trajectory of the write pointer. When the length L and distance D are decoded, the source address src = (wD) mod 32768 is calculated, and it is determined whether the reading range crosses the buffer boundary (i.e., src + L <= 32768). If it does not cross, L bytes are read continuously from the source address. If it crosses, segmented reading is performed, first reading to the end of the buffer, and then reading the remaining bytes from the starting position 0. Finally, the read historical data is output to the Flash and synchronously written to the history buffer to update the sliding window state.

[0048] 4.4 Output Control and Flash Writing Mechanism The decompression function is configured with a maximum output byte count per call (typically 256 bytes). When the output byte count reaches this threshold, or the input buffer runs out of data, the function returns immediately, with the device's main loop controlling whether to continue calling. This decompression function prevents the decompression process from monopolizing CPU resources for extended periods, facilitating concurrent execution with other onboard tasks (such as telemetry acquisition, attitude control, and payload data processing) while avoiding triggering watchdog timeouts in the embedded system.

[0049] Flash writing is implemented using a callback function mechanism: the decompression state machine does not depend on the specific hardware driver and writing method of the Flash, but only calls the externally registered write callback function to complete the data writing; the on-board decompression system can flexibly choose to write to the processor's internal Flash, external SPI Flash, or external storage devices through other bus interfaces according to the hardware configuration, and has extremely strong hardware versatility.

[0050] 5. Resume interrupted download mechanism The onboard decompression system maintains and records in real time the sequence number of the largest consecutive data packet that has been successfully decoded and fully written to Flash memory. When the satellite-to-ground link is interrupted, the ground station can query this largest consecutive data packet sequence number via telemetry commands during the next satellite pass and resume transmission from the data packet corresponding to the breakpoint, i.e., from the next data packet corresponding to the largest consecutive data packet sequence number. Since the DEFLATE decompression process is deterministic, and the decompression state machine can completely save its operating state at the time of interruption, as long as transmission resumes in sequence from the data packet corresponding to the breakpoint, the decompression state machine can correctly resume operation without retransmitting successfully processed data packets, significantly improving transmission reliability in harsh link environments.

[0051] 6. Adaptive data packet size expansion mechanism The data packet size can be flexibly adjusted during packet generation based on the satellite-to-ground link quality, link transmission capacity, and onboard receive buffer size. For example, when channel quality is good, a large 1024-byte packet can be used to reduce the additional overhead of packet splitting; when channel quality is poor and the bit error rate is high, a small 256-byte packet can be used to reduce the retransmission cost caused by single packet errors. The onboard decompression system can automatically adapt to data packets of any size through an input circular buffer, without requiring modification of software code or adjustment of operating configuration, and has extremely strong link adaptability and engineering versatility.

[0052] Example 1: System Hardware Configuration Ground compression system: The computer uses a regular PC, supporting Windows or Linux operating systems, and installs compression and subpackaging modules. The compression and subpackaging modules are integrated into compression and subpackaging software developed based on Qt5.12, with the zlib compression library built-in. Onboard decompression system: The onboard embedded processor uses an STM32 microcontroller with a built-in Cortex-M4 core, a main frequency of 180MHz, 256KB of on-chip RAM, and 16MB of external SPI Flash (W25Q128) as firmware storage medium; Satellite-to-ground link: UHF band telemetry and control link is used, forward link data rate is 4kbps, and the maximum effective payload of a single data packet is 256 bytes.

[0053] Example 2: Ground Compression Subcontracting Process Launch the Qt compression and splitting software, and select the original firmware .bin file to be upgraded; In the configuration interface of the compression and packet splitting software, the target data packet size is entered as 256 bytes, which matches the maximum effective payload of a single transmission of the satellite-to-ground link. Select the output directory for the sub-packet files, click the "Compress and Generate Sub-packet" button, and the subsequent processing flow will be executed automatically. It should be noted that in this example, the sub-packet files refer to the data packet files, and no further distinction will be made thereafter. It automatically reads the original firmware binary file, i.e., the original firmware .bin file, calls the zlib library to perform standard DEFLATE lossless compression, and generates complete compressed data; Extract the 8-byte file identifier header (4-byte magic number + 4-byte original size) from the compressed firmware file and save it separately as a header.bin file; The compressed DEFLATE stream is evenly divided into 256-byte units to generate packet files, which are named packet_0001.bin, packet_0002.bin... packet_xxxx.bin according to the transmission order; The generated header file and all packet files are transmitted to the ground telemetry and control station via storage medium or dedicated network, where the ground station performs subsequent satellite-to-ground transmission.

[0054] Example 3: On-board Streaming Decompression Upgrade Implementation Process After the on-board decompression system is powered on and started, it completes hardware initialization and streaming decompression software module initialization, creates an input ring buffer (4KB) and a ring history buffer (32KB), and initializes the decompression state machine and Flash write callback function; The onboard decompression system enters an upgrade waiting state, prioritizing the reception of the header.bin header file transmitted from the ground. After complete reception, it verifies the magic number field in the header file, confirms the file's legality, extracts the original firmware size information, and creates and initializes the decompression context. The decompression context includes core data such as the input ring buffer management structure, the ring history buffer management structure, the decompression state machine running variables, and the Flash write progress variables. The onboard decompression system enters the main loop, waiting to receive data packet files transmitted from the ground; after each complete data packet file is received, the pure compressed stream payload within the data packet file is written to the input circular buffer, and the write pointer of the circular queue is updated; The main loop calls the decompression processing function, which reads bitstream data from the input circular buffer and drives the decompression state machine to run. The decompression state machine starts from stage 0 by default and gradually completes the entire process of block header parsing, dynamic Huffman tree construction, and data decoding. Whenever the decompression state machine decodes and outputs a valid byte, it calls a pre-registered callback function to synchronously write the byte to the external SPI Flash and the circular history buffer, and at the same time updates the write pointer of the circular history buffer; If the state machine decodes the LZ77 distance / length pair, it enters the matching and copying sub-state, reads the corresponding historical data from the circular history buffer, outputs it byte by byte, and writes it to the Flash and the history buffer. If the input circular buffer is exhausted, the decompression state machine immediately and completely saves all current running states, including bit buffers, Huffman tree structure, matching copy progress, state machine stage identifiers, etc., and returns to the main loop to wait for new data packets to arrive. In the main loop, if the decompression processing function returns a valid output byte count greater than 0, the total number of bytes written to Flash is updated synchronously, and the upgrade progress can be reported to the ground through the telemetry channel; when the total number of bytes written to Flash reaches the original firmware size recorded in the header file, the decompression upgrade is determined to be complete, the main loop is exited, and the firmware verification and switching process is executed. If the satellite-to-ground link is interrupted, causing the data packet transmission to terminate, the onboard decompression system saves the sequence number of the largest consecutive data packet that has been successfully processed and the running status of the decompression state machine in real time. When the satellite passes overhead again, the ground can query the breakpoint information through telemetry commands and resume transmission from the data packet corresponding to the breakpoint. The decompression state machine will seamlessly resume operation from the paused position and continue to complete the decompression and upgrade process.

[0055] Example 4: Circular history buffer matching and copying. When the decompression state machine decodes and obtains a distance / length pair with a matching distance of D and a matching length of L, the on-board decompression system performs the following operations: Define a fixed size for the circular history buffer: HISTORY_SIZE = 32768 bytes, and set the current history buffer write pointer to history_pos; The source starting address of historical data is calculated as: src = (history_pos - D) mod HISTORY_SIZE. Bitwise operations are used to perform address calculations modulo 32768, which improves computational efficiency. Initialize the remaining length to be copied: rem = L; The copy operation is performed repeatedly until the remaining length to be copied, rem, equals 0. Calculate the number of bytes that can be read continuously in the current batch: chunk = HISTORY_SIZE - src. If chunk > rem, then chunk = rem. Starting from the src address of the circular history buffer, copy chunk bytes to the output interface and synchronously write to the current write pointer position of the external Flash and the circular history buffer. If src+chunk==HISTORY_SIZE, it means that the current read has reached the end of the buffer. The next batch of reads should start from the beginning of the buffer and update src to 0. Update the remaining copy length rem = rem - chunk, and synchronously update the history buffer write pointer history_pos; After the matching and copying are completed, the decompression state machine returns to the data decoding stage to continue executing subsequent symbol decoding. This invention perfectly handles scenarios where matching data crosses the boundary of a circular historical buffer, achieving seamless copying while ensuring the cyclic writing and reading of historical data, fully adapting to the LZ77 decompression requirements of the DEFLATE algorithm.

[0056] Example 5: Adaptive Configuration of Data Packet File Size The packet size can be flexibly adjusted based on the actual transmission capacity of the satellite-to-ground link. For example, for the 4kbps UHF link in Example 1, a 256-byte data packet size can balance transmission efficiency and error retransmission costs. If the satellite-to-ground link is upgraded to S-band, increasing the link code rate to 100kbps and the maximum payload per transmission to 1024 bytes, the target data packet size can be directly configured to 1024 bytes in the compression and packetization software, and the packet file can be regenerated. The onboard decompression system can automatically adapt to any data packet size in the range of 64 to 4096 bytes through the input ring buffer, without modifying the software code, adjusting the buffer configuration, or recompiling the program, demonstrating strong link adaptability and engineering versatility.

[0057] Example 6: Resuming interrupted download process Assuming the firmware to be upgraded is compressed and divided into packets, a total of 1000 sequenced data packets need to be transmitted. The satellite-to-ground link is interrupted after the 500th data packet is transmitted. The specific process is as follows: Before the link was interrupted, the on-board decompression system had successfully decompressed and written the data to the 499th data packet in Flash, and recorded the maximum consecutive successful packet sequence number last_ok_seq=499 in real time, while also completely saving the current running state of the decompression state machine. When the satellite passes overhead again, the ground will send a follow-up query telemetry command to the onboard decompression system; After receiving the instruction, the onboard decompression system returned the breakpoint information last_ok_seq=499 to the ground via the telemetry channel; Starting from the 500th data packet, the ground continues to transmit subsequent data packets to the satellite in sequence. During the transmission process, the size of the data packets can be readjusted according to the link quality. After receiving the 500th data packet, the onboard decompression system writes the payload into the input circular buffer and calls the decompression processing function again. The state machine seamlessly recovers from the running state saved when the link was interrupted and continues to execute the decompression process without retransmitting or decompressing the data packets numbered 1 to 499 that have already been processed.

[0058] The beneficial effects of this invention are: (1) Due to the adoption of the ground standard DEFLATE lossless compression and pure compressed stream packetization technology, the typical compression rate for satellite binary firmware can reach 60% to 80%. Under the narrowband satellite-to-ground link of 10kbps, the transmission time of the original firmware of tens of MB can be shortened from several hours / days to 1 to 2 satellite overpasses, so that the firmware upgrade can be completed within a limited single-circle visible arc of a few minutes, which significantly improves the utilization rate of satellite-to-ground link resources.

[0059] (2) Due to the adoption of a fixed-size input circular buffer (4KB) and a circular history buffer (32KB) collaborative architecture, the on-board decompression process does not require caching of the complete compressed file, and the total RAM usage during operation is strictly controlled within 40KB. This directly overcomes the shortcomings of commercial small satellites, which generally use industrial-grade MCUs (with only a few hundred KB of on-chip RAM), and cannot run traditional one-time decompression schemes. It eliminates the need for additional external SRAM expansion or processor upgrades, achieving perfect adaptation to low-cost on-board computing platforms.

[0060] (3) Since the decompression state machine and the dual-ring buffer adopt a streaming data interaction mechanism, the on-board decompression system can start the decoding process immediately after receiving the first data packet, and decouple the link receiving rate and the CPU decompression rate through the read and write pointers of the input buffer. This eliminates the need for the on-board system to reserve a large amount of storage space to cache the full packet data, greatly reducing the dependence on the on-board Flash pre-allocated space, and supporting multi-task concurrent scheduling without triggering the embedded system watchdog timeout.

[0061] (4) Because the decompression state machine is an interruptible snapshot architecture, it can completely save all intermediate variables such as bit buffer, Huffman tree structure, LZ77 matching progress and stage identifier when the input buffer is exhausted or the link is interrupted; combined with the telemetry confirmation mechanism of the maximum consecutive successful data packet sequence number, the ground can seamlessly resume transmission from the breakpoint sequence number, and the decompression state machine is accurately restored to the paused position. It completely avoids the defects of traditional solutions that require retransmission or re-decompression after interruption, and is particularly suitable for the transmission characteristics of low-orbit satellites frequently passing overhead and links being easily blocked.

[0062] (5) Since the data packet segmentation granularity supports software configuration within the range of 64 to 4096 bytes, the ground can dynamically adjust the packet size according to the UHF / S band link quality, bit error rate, and telemetry and control system, balancing transmission efficiency and retransmission cost. At the same time, Flash writing adopts a callback function mechanism, and the decompression core logic is not bound to a specific memory driver, which can flexibly adapt to different media such as on-chip Flash, SPI Flash, QSPI Flash, or SD card. This allows the present invention to be ported to various spaceborne devices across platforms without modifying the core algorithm code.

[0063] (6) This invention is based entirely on the software-level reconstruction of the firmware upgrade process. The ground uses the standard zlib ecosystem toolchain, and the satellite is implemented based on a lightweight C language state machine, without the need to introduce dedicated compression chips, FPGAs, or radiation-resistant large-capacity memory. Under the premise of ensuring high compression ratio and high reliability of transmission, it achieves 100% reuse of satellite hardware resources, significantly reduces the single-satellite BOM cost and system integration complexity, and provides a standardized and mass-producible technical foundation for the large-scale on-orbit maintenance of low-Earth orbit commercial constellations.

[0064] The above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A method for streaming compression upgrade of firmware for spaceborne equipment in commercial aerospace, implemented by a system for streaming compression upgrade of firmware for spaceborne equipment in commercial aerospace, characterized in that: This includes the ground-based compression and packaging phase and the onboard streaming decompression and upgrade phase; The ground compression subcontracting stage includes the following steps: S1: Obtain the original firmware binary file to be upgraded, and use the standard DEFLATE algorithm to perform lossless compression on the original firmware binary file to generate a compressed firmware file; S2: Extract the file identifier header of the compressed firmware file. The file identifier header includes at least a magic number field and an original firmware binary file size field. Save the file identifier header as a header file. S3: Divide the compressed firmware file according to the preset target data packet size to generate multiple independent data packet files, wherein the data packet files only include pure compressed stream segments; The on-board streaming decompression and upgrade stage includes the following steps: S4: The on-board decompression system receives the file identifier header, verifies the magic number field to confirm the file's legality, and then extracts the original firmware binary file size field; the on-board decompression system uses a pre-configured input circular buffer and a circular history buffer for decompression processing; S5: The on-board decompression system receives the data packet files sequentially and writes the pure compressed stream segments in the data packet files into the input circular buffer; S6: Call the decompression processing function to drive the decompression state machine to read bitstream data from the input circular buffer for decoding; S7: When the decompression state machine decodes and outputs a valid byte, the valid byte is synchronously written to the external non-volatile memory and the circular history buffer; S8: When the input circular buffer is exhausted, the decompression state machine pauses operation and saves the current running state completely, waiting for a new data packet to arrive before resuming operation, until the total number of bytes of decompression output reaches the size of the original firmware binary file.

2. The method for firmware streaming compression upgrade of spaceborne equipment for commercial aerospace as described in claim 1, characterized in that: In step S2, the file identifier header is 8 bytes long; the magic number field is 4 bytes long and is set to 0x44454C46; the original firmware binary file size field is 4 bytes long and is a 32-bit unsigned integer.

3. The method for firmware streaming compression upgrade of spaceborne equipment for commercial aerospace as described in claim 1, characterized in that: In step S3, the target data packet size is configured based on the single transmission capacity of the satellite-to-ground link and the size of the on-board receiving buffer, with a value range of 64 bytes to 4096 bytes; the data packet file is named and encoded according to the transmission order.

4. The method for firmware streaming compression upgrade of spaceborne equipment for commercial aerospace as described in claim 1, characterized in that: In step S4, the size of the input circular buffer is set to 4KB, and a circular queue structure is used for implementation; In step S5, the on-board decompression system writes the received data packet payload into the current write pointer position of the input circular buffer and updates the write pointer. In step S6, the decompression state machine reads bitstream data from the current read pointer position of the input circular buffer and updates the read pointer; In step S8, when the read pointer and the write pointer address coincide, it is determined that the input circular buffer is exhausted.

5. The method for firmware streaming compression upgrade of spaceborne equipment for commercial aerospace as described in claim 1, characterized in that: In step S4, the size of the circular history buffer is set to 32KB and allocated in the on-board RAM; In step S7, the valid byte is written to the current write pointer position of the circular history buffer, and the write pointer is then incremented cyclically by a modulus of 32KB. When the decompression state machine decodes the distance / length pair, it calculates the source data address based on the current write pointer and the matching distance, and continuously reads historical data of a specified length from the source data address for matching and copying.

6. The method for firmware streaming compression upgrade of spaceborne equipment for commercial aerospace as described in claim 5, characterized in that: The expression for calculating the source data address is as follows: Source address = (write pointer - match distance) mod 32768; If the reading process crosses the end boundary of the circular history buffer, segmented reading is automatically performed. First, the reading reaches the end of the circular history buffer, and then the remaining bytes are read from the beginning of the circular history buffer.

7. The method for firmware streaming compression upgrade of spaceborne equipment for commercial aerospace as described in claim 1, characterized in that: In step S8, the decompression state machine includes three core operating phases: phase 0 is the block header parsing phase, phase 1 is the data decoding phase, and phase 2 is the dynamic Huffman tree construction phase. The fully saved current running state includes: the Huffman tree structure currently being decoded, the code length sequence padding position, the number of bytes remaining for matching and copying, the bit buffer data, and the current stage identifier; The step of waiting for a new data packet to arrive before resuming operation includes: when a new data packet arrives, the decompression state machine resumes from the previously saved running state and continues to execute the decoding process.

8. The method for firmware streaming compression upgrade of spaceborne equipment for commercial aerospace as described in claim 1, characterized in that: It also includes a breakpoint resume step: the on-board decompression system maintains and records in real time the sequence number of the largest consecutive data packet that has been successfully decoded and completely written to the external non-volatile memory; When the satellite-to-ground link is interrupted, the ground station will query the sequence number of the largest consecutive data packet via telemetry commands when the satellite passes overhead again. The ground station continues transmission starting from the next data packet corresponding to the largest consecutive data packet sequence number; After receiving subsequent data packets, the on-board decompression system seamlessly resumes operation from the running state saved when the link was interrupted.

9. The method for firmware streaming compression upgrade of spaceborne equipment for commercial aerospace as described in claim 1, characterized in that: In step S7, the writing to the external non-volatile memory is implemented using a callback function mechanism; The decompression processing function includes configuring the maximum number of output bytes per call, and returning immediately when the number of output bytes reaches the threshold or the input circular buffer is exhausted.

10. The method for firmware streaming compression upgrade of spaceborne equipment for commercial aerospace as described in claim 1, characterized in that: The satellite-borne equipment firmware streaming compression upgrade system for commercial aerospace includes a ground compression system and an on-board decompression system; the ground compression system is used to execute the ground compression sub-packaging stage steps as described in any one of claims 1 to 3; the on-board decompression system includes an on-board embedded processor, an external non-volatile Flash memory, and a streaming decompression software module; the streaming decompression software module has a built-in input circular buffer, an interruptible and recoverable decompression state machine, a circular history buffer, and a Flash write controller, used to execute the on-board streaming decompression upgrade stage steps as described in any one of claims 1, 4 to 9.

Images