A load software reconstruction method of LEO satellite

Abstract

This invention provides a payload software reconfiguration method for LEO satellites, applicable to ground control stations, payload management equipment within LEO satellites, and target payload units. The method divides the payload software reconfiguration of the target payload unit into two stages: In the first stage, within the data transmission arc, the ground control station fully utilizes the uplink bandwidth of the space-to-ground data transmission link to rapidly upload the software reconfiguration file to the payload management equipment for storage. In the second stage, the payload management equipment transmits the software reconfiguration file to the target payload unit via the internal interconnection bus, thus achieving software reconfiguration of the target payload unit. Furthermore, the accuracy of the software reconfiguration file transmission can be quickly determined through the first feedback information sent by the payload management equipment and the second reception feedback information sent by the target payload unit, allowing for timely re-transmission of the software reconfiguration file. Therefore, this method effectively improves the efficiency and accuracy of payload software reconfiguration for LEO satellites.

Description

Technical Field

[0001] This invention relates to the field of aerospace electronics technology, and specifically to a payload software reconfiguration method for LEO satellites. Background Technology

[0002] With the accelerated development cycle of satellites, payload software reconfiguration has become a crucial means of improving functionality and expanding mission capabilities during the post-launch and on-orbit phases of the payload system. Typically, the payload software reconfiguration process involves the ground station uplinking the reconfiguration file to the satellite data receiver, which then forwards it in real-time to the payload unit via the payload management computer's internal bus, enabling the replacement and upgrade of the payload software. The status of the payload software reconfiguration process can be monitored via telemetry downlink. However, the information exchange between the payload unit and the payload management computer is asymmetrical, and the size of the payload software reconfiguration file is usually in the range of several hundred KB to several MB.

[0003] Because the visible data transmission arc over low Earth orbit (LEO) satellites is relatively short (typically 8 minutes) per revolution, if the aforementioned method of real-time transparent forwarding from the payload management computer to the payload unit is used, the bandwidth of the slow command and control bus between the payload computer and the payload unit is limited, typically restricting the effective uplink injection frame rate between space and ground, and failing to fully utilize the high-speed uplink capability of the data transmission link. Furthermore, ground stations typically do not perform frame-to-frame confirmation and retransmission operations with the satellite, and the space-ground link usually suffers from bit error rates and instability. During the reconstructed file uploading process, the payload unit still requires ground operators to perform multiple confirmation interactions based on the uplink and downlink telemetry readings from the satellite.

[0004] This results in only a portion of the reconstructed file being completed during a single uplink transmission arc. A complete payload software reconstruction, which can be several MB in size, requires multiple attempts and can take several days to complete. This increases the complexity of payload software reconstruction, reduces its accuracy, and impacts the overall satellite mission efficiency. Therefore, the existing methods cannot efficiently and accurately achieve payload software reconstruction for LEO satellites. Summary of the Invention

[0005] The technical problem to be solved by this invention is the inability to efficiently and accurately reconfigure the payload software of LEO satellites.

[0006] To address the aforementioned technical problems, this invention provides a payload software reconfiguration method for LEO satellites, specifically employing the following technical solution: Firstly, this invention provides a payload software reconfiguration method for LEO satellites, applicable to payload management equipment installed in LEO satellites. The method includes: First, the payload management equipment receives each injected data frame from each sub-partition sent by a ground control station via a space-to-ground data transmission link. Each injected data frame includes a corresponding area code and an intra-group offset number. The area code represents the sub-partition number where the injected data frame is located, and the intra-group offset number represents the position of the injected data frame within its sub-partition. Each sub-partition is obtained by the ground control station partitioning and framing the software reconfiguration file of the target payload unit according to a preset size. Each sub-partition includes multiple injected data frames. Then, the payload management equipment performs a first integrity check on the injected data frames. If an injected data frame fails the first integrity check, it is discarded. If an injected data frame passes the first integrity check, it is stored in a partition based on the area code and intra-group offset number corresponding to the injected data frame. Next, based on the number of injected data frames stored in the partition, a first feedback message is sent to the ground control station. This first feedback message represents the reception status of injected data frames in each sub-partition. Secondly, the payload management device integrates the injected data frames from the partitioned storage to obtain the received file, and performs a second integrity check on the received file. Further, if the received file passes the second integrity check, the payload management device determines that the received file is a software reconstruction file, and divides the software reconstruction file into multiple sub-packet files according to a preset packet length, each sub-packet file corresponding to a packet sequence number. Finally, in response to the injection command sent by the ground control station, the payload management device sequentially sends the multiple sub-packet files to the target payload unit at preset time intervals in ascending order of packet sequence numbers, so that the target payload unit can initiate reconstruction operation based on the software reconstruction file composed of multiple sub-packet files.

[0007] This method divides payload software reconstruction into two stages: In the first stage, within the data transmission arc, the ground control station fully utilizes the uplink bandwidth of the space-to-ground data transmission link to rapidly upload the software reconstruction file to the payload management device for storage. In the second stage, outside the data transmission arc, the payload management device can transmit the software reconstruction file to the target payload unit via the payload's internal interconnection bus, thus achieving software reconstruction for the target payload unit. This method simplifies the software reconstruction of the payload unit. Within the payload's internal interconnection information transmission framework, it fully utilizes the uplink bandwidth of the space-to-ground data transmission link and the payload's internal confirmation protocol, enabling LEO satellites to complete software reconstruction file uploading within a single data transmission arc and switch the payload unit to the new reconstruction program in the next telemetry and control arc. Furthermore, the first feedback information sent by the payload management device to the ground control station and the second reception feedback information sent by the target payload unit to the payload management device quickly determine whether the software reconstruction file has been transmitted completely and accurately. It also allows for the retransmission of the software reconstruction file even if it has not been transmitted accurately. In summary, this LEO satellite payload software reconfiguration method can effectively improve the efficiency and accuracy of LEO satellite payload software reconfiguration.

[0008] In conjunction with the first aspect, in one alternative implementation, the aforementioned first feedback information is a partition bitmap, which includes multiple grids, each corresponding one-to-one with multiple sub-partitions. The aforementioned sending of the first feedback information to the ground control station based on the number of injected data frames stored in the partitions includes: First, the payload management device determines whether each injected data frame in each sub-partition has been received based on the number of injected data frames stored in the partitions. Then, if each injected data frame in the sub-partition has been received, the payload management device sets the value of the grid corresponding to the sub-partition in the partition bitmap to 1 and sends the partition bitmap to the ground control station. If any injected data frames in a sub-partition have not been received, the payload management device sets the value of the grid corresponding to the sub-partition in the partition bitmap to 0 and sends the partition bitmap to the ground control station.

[0009] In this implementation, using a partition bitmap as the first feedback information can effectively and quickly provide feedback on the reception status of the injected data frames in each sub-partition by the load management device.

[0010] In conjunction with the first aspect, in one alternative implementation, the method further includes: First, if the received file fails the second integrity check, the payload management device receives each injected data frame from the retransmission partition resent by the ground control station; the retransmission partition is a sub-partition where the injected data frames, as determined by the ground control station based on the first feedback information, have not been fully received. Then, the payload management device replaces the injected data frames stored in the partition according to the area number and group offset number corresponding to each injected data frame in the retransmission partition.

[0011] In this implementation, even if the received file fails the second integrity check, the payload management device can still receive each injected data frame from the retransmission partition determined by the ground control station based on the first feedback information. This improves the accuracy and success rate of the payload management device receiving injected data frames.

[0012] In conjunction with the first aspect, in one alternative implementation, the method further includes: First, the load management device receives second reception feedback information sent by the target load unit. This second reception feedback information characterizes the target load unit's reception status of the sub-packet files, and includes the packet sequence number corresponding to each sub-packet file. Then, with the packet sequence number in the second reception feedback information remaining unchanged for a consecutive preset time, the load management device, starting from the sub-packet file corresponding to the next packet sequence number after the unchanged packet sequence number, re-sends the sub-packet files to the target load unit sequentially at preset time intervals, in ascending order of packet sequence number, until the target load unit receives each sub-packet file constituting the software reconfiguration file.

[0013] In this implementation, the load management device can determine the target load's reception status of the sub-packet file based on the second reception feedback information sent by the target load unit. Furthermore, if the sub-packet file received by the target load unit fails the sub-packet verification, it can resend the sub-packet file to the target load unit starting from the sub-packet file that failed the verification. This improves the accuracy and success rate of the target load unit receiving the sub-packet file.

[0014] In conjunction with the first aspect, in one alternative implementation, the method further includes: if the target payload unit fails to initiate reconstruction based on the software reconstruction file, the load management device performs a third integrity check on the received file. If the received file passes the third integrity check, the load management device resends multiple sub-packet files to the target payload unit in ascending order of packet sequence number at preset time intervals.

[0015] In this implementation, if the received file passes the third integrity verification, there is no need for the ground control station to transmit the software reconstruction file to the payload management device again. Instead, the payload management device directly resends the sub-packet file to the target payload unit, thereby improving the efficiency of payload software reconstruction.

[0016] Secondly, this invention provides a payload software reconfiguration method for LEO satellites, applicable to a target payload unit installed within an LEO satellite. The method includes: First, the target payload unit receives sub-packet files sent by a payload management device at preset time intervals in ascending order of packet sequence numbers. Each sub-packet file is obtained by the payload management device dividing the target payload unit's software reconfiguration file into packets according to a preset packet length, and each sub-packet file corresponds to a packet sequence number. Then, the target payload unit performs sub-packet verification based on the packet sequence number corresponding to the sub-packet file. Next, if the sub-packet file passes the sub-packet verification, the target payload unit saves the sub-packet file and sends second reception feedback information to the payload management device. This second reception feedback information characterizes the reception status of the sub-packet file and includes the packet sequence number corresponding to the sub-packet file. Finally, upon receiving each sub-packet file constituting the software reconfiguration file, the target payload unit, in response to an operation command sent by a ground control station, initiates reconfiguration operation based on the software reconfiguration file.

[0017] In conjunction with the second aspect, in one alternative implementation, the method further includes: First, if a sub-packet file fails sub-packet verification, the target payload receiver discards the sub-packet file and sends second reception feedback information to the payload management device. The second reception feedback information includes the packet sequence number corresponding to the previously received and saved sub-packet file. Then, the target payload receiver, starting with the sub-packet file corresponding to the packet sequence number determined based on the second reception feedback information, re-sends sub-packet files sequentially at preset time intervals in ascending order of packet sequence number, and performs sub-packet verification based on the packet sequence number corresponding to the sub-packet file, until each sub-packet file constituting the software reconfiguration file is received.

[0018] In conjunction with the second aspect, in an alternative implementation, the method further includes: if the target payload single-machine receiver fails to initiate reconstruction operation based on the software reconstruction file, it restores to the operating state before the reconstruction operation was initiated, and re-receives the sub-packet files sent by the payload management device at preset time intervals in ascending order of packet sequence number after the received file has passed the third integrity verification.

[0019] Thirdly, this invention provides a payload software reconfiguration method for LEO satellites, applicable to ground control stations. These ground control stations transmit data with payload management equipment located within the LEO satellite via a space-to-ground data transmission link. The method includes: First, the ground control station partitions and frames the software reconfiguration file of the target payload unit according to a preset size, determining multiple sub-partitions. Each sub-partition includes multiple injected data frames. Each injected data frame includes a corresponding area code and an intra-group offset number. The area code represents the sub-partition number where the injected data frame is located, and the intra-group offset number represents the position of the injected data frame within its sub-partition. Then, within the data transmission arc, the ground control station sends each injected data frame from each sub-partition within the multiple sub-partitions to the payload management equipment via the space-to-ground data transmission link.

[0020] In conjunction with the third aspect, in an alternative implementation, the method further includes: the ground control station receiving first feedback information sent by the payload management equipment, the first feedback information being used to characterize the reception status of injected data frames in each sub-segment. After the ground control station sends each injected data frame from each sub-segment in multiple sub-segments to the payload management equipment, it determines, based on the first feedback information, whether there is a retransmission partition, where the retransmission partition is a sub-segment where injected data frames were not completely received. If a retransmission partition exists, the ground control station retransmits each injected data frame in the retransmission partition to the payload management equipment via the space-ground data transmission link.

[0021] Fourthly, the present invention provides an electronic device, comprising: a memory and one or more processors; the memory being coupled to the processors; wherein the memory stores computer program code, the computer program code including computer instructions, which, when executed by the processor, cause the electronic device to perform the method provided by the first aspect and any of its alternative implementations.

[0022] Fifthly, the present invention provides a computer-readable storage medium including computer instructions that, when executed on an electronic device, cause the electronic device to perform the method provided by the first aspect and any alternative implementation thereof.

[0023] Understandably, the beneficial effects of the electronic device of the fourth aspect and the computer-readable storage medium of the fifth aspect can be referenced to the beneficial effects of the first aspect and any of its possible design embodiments, which will not be repeated here. Attached Figure Description

[0024] Figure 1 A flowchart illustrating the process of reconfiguring onboard payload software for related technologies; Figure 2 A flowchart illustrating the payload software reconfiguration method for LEO satellites provided in this application embodiment. Figure 1 ; Figure 3 A schematic diagram illustrating the software reconstruction file partitioning, framing, and grouping provided in an embodiment of this application; Figure 4 A schematic diagram of a partition bitmap provided in an embodiment of this application; Figure 5 A flowchart illustrating the payload software reconfiguration method for LEO satellites provided in this application embodiment. Figure 2 ; Figure 6 This is a schematic diagram illustrating the transmission of sub-packet files from a load management device to a target load unit, as provided in an embodiment of this application. Figure 7 A flowchart illustrating the payload software reconfiguration method for LEO satellites provided in this application embodiment. Figure 3 . Detailed Implementation

[0025] The embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described below do not represent all embodiments consistent with this application. They are merely examples of systems and methods consistent with some aspects of this application as detailed in the claims.

[0026] As satellite development cycles accelerate, payload software reconfiguration has become an important means of improving functionality and expanding missions after satellite launch and during the on-orbit phase of the payload unit. Figure 1 A flowchart illustrating the onboard payload software reconfiguration process for related technologies, such as... Figure 1 As shown, the typical payload software reconfiguration process is as follows: the ground station uploads the reconfiguration file to the satellite data receiver, and then the payload management computer forwards it in real time to the payload units (e.g., payload unit 1, payload unit 2... payload unit n) via the payload system's internal bus to achieve payload software replacement and upgrade. The status of the payload software reconfiguration process can be monitored via downlink telemetry based on the telemetry and control status.

[0027] However, the information exchange between the payload unit and the payload management computer is asymmetrical, typically employing a combination of slow command and control lines (e.g., 1553B, CAN bus, RS422 bus) and high-speed unidirectional data lines (e.g., LVDS bus, 2711 interface). The payload management computer transmits mainly low-volume data injections of commands or configuration parameters to the payload unit, occurring on slow command and control lines, often without additional high-speed bus support. Furthermore, the size of the payload software reconstruction file is typically in the range of several hundred KB to several MB. Especially for field-programmable gate array (FPGA) software or system-on-programmable chip (SOPC) software, the reconstruction file size can reach as high as 10MB-20MB.

[0028] Because the visible data transmission arc over the LEO satellite's ground data transmission station is relatively short (typically 8 minutes), if the aforementioned method of real-time transparent forwarding from the payload management computer to the payload unit is adopted, the bandwidth of the slow command and control bus between the payload computer and the payload unit is limited, typically restricting the effective uplink injection frame rate between space and ground, and failing to fully utilize the high-speed uplink capability of the data transmission link. Furthermore, ground stations typically do not perform frame-to-frame confirmation and retransmission operations with the satellite, and the space-ground link usually suffers from bit error rates and instability. During the reconstructed file uploading process, the payload unit still requires ground operators to perform multiple confirmation interactions based on the satellite's uplink and downlink telemetry interpretations (including verification checks of reconstructed sections, retransmission of lost injection frames, etc.).

[0029] This results in only a portion of the reconstructed file being completed during a single uplink segment, while a complete payload software reconstruction, typically several MB in size, requires multiple attempts and can take several days to complete. This increases the complexity and reduces the accuracy of payload software reconstruction, impacting the overall mission efficiency. Therefore, the existing methods cannot efficiently and accurately achieve payload software reconstruction for LEO satellites.

[0030] To address the aforementioned issues, this application provides a payload software reconfiguration method for LEO satellites. This method divides the payload software reconfiguration into two stages: In the first stage, within the data transmission arc, the ground control station fully utilizes the uplink bandwidth of the space-to-ground data transmission link to rapidly upload the reconfiguration file to the payload management device for caching. In the second stage, outside the data transmission arc, the payload management device can transfer the reconfiguration file to the target payload unit via the payload's internal interconnection bus (e.g., command and control line) to achieve software reconfiguration of the target payload unit. This method simplifies the software reconfiguration of the payload unit through a unified design. Within the payload's internal interconnection information transmission framework, it fully utilizes the uplink bandwidth of the space-to-ground data transmission link and the payload's internal confirmation protocol, enabling LEO satellites to complete the uploading of payload software reconfiguration files within a single data transmission arc and control the payload unit to switch to the new reconfiguration program in the next control arc. This effectively improves the efficiency and accuracy of LEO satellite payload software reconfiguration.

[0031] The solutions provided in the embodiments of this application will be described below with reference to the accompanying drawings.

[0032] Specifically, the LEO satellite payload software reconfiguration method provided in this application embodiment can be applied to an LEO satellite payload software reconfiguration system. This system includes a ground control station, a payload management device installed within the LEO satellite, and a target payload unit. The payload management device can be, for example, a payload management computer, and the target payload unit is the payload unit to be reconfigured. The ground control station and the payload management device can transmit data via a space-to-ground data transmission link, and the payload management device and the target payload unit can transmit data via an internal interconnection bus (e.g., a payload command bus). Figure 2 A flowchart illustrating the payload software reconfiguration method for LEO satellites provided in this application embodiment. Figure 1 ,like Figure 2 As shown, the payload software reconfiguration method for LEO satellites provided in this application includes the following steps S101-S113: S101. The ground control station divides and frames the software reconstruction file of the target payload unit according to the preset size, and determines multiple sub-partitions.

[0033] First, to facilitate the rapid and accurate uploading of software reconfiguration files to the payload management equipment, the ground control station can divide the software reconfiguration files into multiple sub-regions according to a preset size.

[0034] The software reconstruction file is used for software reconstruction of the target payload. The preset size can be determined based on LEO satellite parameters (e.g., bus protocol parameters) and actual application requirements; this application does not impose specific limitations on this. Each sub-partition includes multiple injected data frames. Each injected data frame includes a corresponding area number and an intra-group offset number. The area number indicates the sub-partition number where the injected data frame resides, and the intra-group offset number indicates the position of the injected data frame within its sub-partition. This facilitates partitioned storage by the payload management equipment based on the area number and intra-group offset number of the injected data frames, and also facilitates verification of the integrity of the received files.

[0035] For example, Figure 3 This is a schematic diagram of software reconstruction file partitioning, framing, and grouping provided in an embodiment of this application, as shown below. Figure 3 As shown, the ground control station can divide the software reconstruction file into n sub-partitions according to a preset size, and each sub-partition can include 2048 injected data frames.

[0036] S102, the ground control station sends each injected data frame of each sub-partition in multiple sub-partitions to the load management equipment through the space-ground data transmission link within the data transmission arc.

[0037] Specifically, the ground control station can transmit each injected data frame of each sub-partition to the payload management equipment at high speed via the ground-to-ground data transmission link within a data transmission arc.

[0038] Among them, the space-to-ground data transmission link is characterized by high speed and high bandwidth. Therefore, the ground control station can quickly send injected data frames to the payload management equipment through the space-to-ground data transmission link.

[0039] S103. The payload management equipment receives each injected data frame from each sub-partition sent by the ground control station through the space-ground data transmission link.

[0040] S104. The load management device performs the first integrity check on the injected data frame.

[0041] Specifically, the load management device can perform a first integrity check on the received injected data frame to determine whether the injected data frame is a correct and complete data frame, so as to further determine whether to save the received injected data frame.

[0042] For example, the first integrity check may include: matching the frame header signature and data type of the data frame, and ensuring that the frame data satisfies CRC check (e.g., CRC-16 checksum).

[0043] S105. If the injected data frame fails the first integrity check, the load management device discards the injected data frame.

[0044] S106. If the injected data frame passes the first integrity check, the load management device determines the partition storage based on the area number and group offset number corresponding to the injected data frame.

[0045] Specifically, after the injected data frame passes the first integrity check, the load management device can determine the storage area based on the area number corresponding to the injected data frame. This storage area corresponds one-to-one with the sub-partition. Then, based on the intra-group offset number corresponding to the injected data frame, the injected data frame is stored at the corresponding location in the storage area to achieve partitioned storage of the injected data frame.

[0046] S107. The load management device sends the first feedback information to the ground control station based on the number of injected data frames stored in the partition.

[0047] The first feedback information is used to characterize the reception status of injected data frames in each sub-segment. Specifically, the payload management device can use the first feedback information (e.g., downlink telemetry digital quantity) to report the reception status of injected data frames in each sub-segment to the ground control station, so that if injected data frames are not received or if there are integrity issues with the injected data frames, the ground control station can resend the injected data frames based on the first feedback information.

[0048] In some embodiments, the first feedback information described above may be a partition bitmap. Figure 4 This is a schematic diagram of the partition bitmap provided in the embodiments of this application, such as... Figure 4 As shown, the partition bitmap includes multiple grids, each corresponding to a sub-partition. Then, based on the number of injected data frames stored in the partition, S107 sends first feedback information to the ground control station, which may specifically include: First, the load management device determines whether each injected data frame in each sub-partition has been received based on the number of injected data frames stored in the partition.

[0049] Then, with each injected data frame in the sub-partition being received, the load management device sets the value of the grid corresponding to the sub-partition in the partition bitmap to 1 and sends the partition bitmap to the ground control station.

[0050] For example, such as Figure 4 As shown, if every injected data frame in sub-partition A101 is received, the value of raster B101 corresponding to sub-partition A101 in the partition bitmap can be set to 1.

[0051] If an injected data frame is not received in a sub-partition, the load management device sets the value of the grid corresponding to the sub-partition in the partition bitmap to 0 and sends the partition bitmap to the ground control station.

[0052] For example, such as Figure 4 As shown, if there are unreceived injected data frames in sub-partition A112, the value of raster B112 corresponding to sub-partition A112 in the partition bitmap can be set to 0.

[0053] S108, The ground control station receives the first feedback information sent by the load management equipment.

[0054] S109. After the ground control station sends each injected data frame of each sub-partition to the load management device in multiple sub-partitions, it determines whether there is a resend partition based on the first feedback information.

[0055] Specifically, during the reconstruction and injection process, the ground control station can determine whether there is a retransmission partition based on the first feedback information received. The retransmission partition is a sub-partition where the injected data frame was not completely received.

[0056] For example, if every injected data frame in sub-partition A has been sent, but the payload management device has not received all the injected data frames in sub-partition A according to the first feedback information, then sub-partition A is designated as a resend partition.

[0057] S110, the ground control station, in the presence of a resend partition, resends each injected data frame in the resend partition to the load management equipment via the space-ground data transmission link.

[0058] In this embodiment of the application, when a retransmission partition exists, the ground control station will retransmit each injected data frame in the retransmission partition, that is, all injected data frames, to the payload management device through the space-ground data transmission link to further improve the success rate of the payload management device receiving the injected data frames.

[0059] S111, The load management device integrates the injected data frames from the partitioned storage to obtain the received file, and performs a second integrity check on the received file.

[0060] Meanwhile, the payload management equipment performs a second integrity check on the received file to determine whether the complete received file, i.e. the complete software reconstruction file, has been accurately received, in order to further determine whether each injected data frame in the retransmission partition resent by the ground control station has been received.

[0061] For example, the second integrity check can be: matching the characteristic characters of the file header and footer to ensure that the file data meets the CRC check (such as CRC-16 or CRC-32 check code).

[0062] S112. If the received file fails the second integrity check, the payload management device receives each injected data frame in the resent partition retransmitted by the ground control station.

[0063] S113. The load management device replaces the injected data frames stored in the partition according to the area number and group offset number corresponding to each injected data frame in the resending partition.

[0064] Specifically, the storage area in the payload management device that did not receive all injected data frames will be referred to as storage area A, which corresponds to the retransmission partition.

[0065] In one implementation, the payload management device can retain the received injected data frames in storage area A without erasing them. Instead, it replaces the injected data frames in storage area A with each newly received retransmission partition. This reduces the failure rate of the same injected data frame in storage area A from p to pf. 2 This can effectively improve the success rate of load management devices receiving injected data frames.

[0066] The first stage of the LEO satellite payload software reconfiguration method provided in this application embodiment can be achieved through the above-described S101-S113 steps, namely, the ground control station sends the software reconfiguration file to the payload management device via the space-to-ground data transmission link, and the payload management device stores the software reconfiguration file. Next, the second stage of the LEO satellite payload software reconfiguration method is achieved through the following method: the payload management device transmits the software reconfiguration file to the target payload unit, so that the target payload unit can initiate reconfiguration operation according to the software reconfiguration file. Specifically, Figure 5 A flowchart illustrating the payload software reconfiguration method for LEO satellites provided in this application embodiment. Figure 2 ,like Figure 5 As shown, the method also includes: S114. If the received file passes the second integrity check, the load management device determines that the received file is a software reconstruction file, and performs packet processing on the software reconstruction file according to the preset packet length to obtain multiple sub-packet files, each sub-packet file corresponding to a packet sequence number.

[0067] The preset packet length can be preset according to the parameters of the LEO satellite (such as bus protocol parameters) and the needs of actual applications; this application does not impose specific limitations on it. The payload management device divides the software reconstruction file into multiple sub-packet files according to the preset packet length, which facilitates the transmission of the software reconstruction file to the target payload.

[0068] S115. In response to the upload command sent by the ground control station, the load management equipment sends multiple sub-package files to the target load unit in a preset time interval and in ascending order of package number.

[0069] In this way, the target payload unit can initiate reconstruction operation based on a software reconstruction file composed of multiple sub-package files. Specifically, the ground control station can send an injection command to the payload management device in S102, which is the next arc of the data transmission arc (e.g., the telemetry and control arc) of the injected data frame. This causes the payload management device to respond to the injection command by sending sub-package files to the target payload unit, thereby transmitting the software reconstruction file to the target payload unit.

[0070] In this embodiment, the load management device can send multiple sub-packet files to the target load unit in ascending order of packet number at preset time intervals. This allows the target load unit to verify the received sub-packet files, thereby improving the accuracy and success rate of the target load unit receiving the sub-packet files.

[0071] In one implementation, step S115 can be performed on a satellite outside the telemetry and control area. The payload management device can send sub-packet files to the target payload unit via the payload internal interconnection bus (e.g., command telemetry and control line, payload command bus). This improves the stability of sub-packet file transmission.

[0072] S116. The target payload unit receives sub-packet files sent by the payload management device at preset time intervals in ascending order of packet sequence number.

[0073] S117. The target payload performs sub-packet verification based on the package sequence number corresponding to the sub-packet file.

[0074] Specifically, sub-packet verification can include: packet sequence number order verification and sub-packet file integrity verification. Since the payload management device sends sub-packet files in ascending order of packet sequence number, the target payload unit can determine whether it has received the sub-packet files in complete and sequential order by verifying the packet sequence number order. Furthermore, the target payload unit can also determine the integrity of each sub-packet file by verifying the integrity of the sub-packet files, further improving the accuracy of the target payload unit's reception of sub-packet files.

[0075] S118. If the sub-package file passes the sub-package verification, the target payload unit saves the sub-package file and sends the second reception feedback information to the payload management device.

[0076] The second reception feedback information is used to characterize the reception status of the sub-packet file. If the sub-packet file passes the sub-packet verification, the second reception feedback information includes the packet sequence number (AckIdx) corresponding to the sub-packet file.

[0077] S119. If the sub-package file fails the sub-package verification, the target payload unit discards the sub-package file and sends a second reception feedback message to the payload management device.

[0078] Specifically, if a sub-packet file fails the sub-packet verification, the target payload unit discards the sub-packet file, stops receiving subsequent sub-packet files, and sends a second reception feedback message. In this case, the second reception feedback message includes the packet sequence number corresponding to the previous sub-packet file that was received and saved (i.e., successfully received).

[0079] S120, The load management device receives the second reception feedback information sent by the target load unit.

[0080] S121. If the packet sequence number in the second received feedback information remains unchanged for a continuous preset time, the load management device will start from the sub-packet file corresponding to the next packet sequence number of the unchanged packet sequence number, and send the sub-packet files to the target load unit in ascending order of packet sequence number at preset time intervals until the target load unit receives each sub-packet file that constitutes the software reconstruction file.

[0081] Specifically, if the packet sequence number in the second received feedback information remains unchanged for a preset time (e.g., 3 seconds), it can be determined that there are sub-packet files in the target payload unit that have failed the sub-packet verification, and the target payload unit stops receiving subsequent sub-packet files. Therefore, the load management device starts from the sub-packet file corresponding to the next packet sequence number after the unchanged packet sequence number and re-sends the sub-packet files to the target payload unit in ascending order of packet sequence number at preset time intervals, so as to continue sending the correct sub-packet files to the target payload unit.

[0082] S122. If the target payload unit fails the sub-packet verification, it receives the sub-packet files sent by the payload management device starting with the sub-packet file corresponding to the packet sequence number determined based on the second reception feedback information, and then sends the sub-packet files sequentially in ascending order of packet sequence number at preset time intervals. It then performs sub-packet verification based on the packet sequence number corresponding to the sub-packet file until it receives each sub-packet file that constitutes the software reconstruction file.

[0083] For example, Figure 6 This is a schematic diagram illustrating the transmission of sub-packet files from the load management device to the target load unit, as provided in the embodiments of this application. Figure 6As shown, the load management device sends sub-packet files in ascending order of packet sequence number, with the packet sequence numbers being: Mk, ..., M-2, M-1, M, M+1, M+2, M+3, M+4, ..., M+m, ... During the reception of sub-packet files, the target load unit sends a second reception feedback message to the load management device, which includes the packet sequence number. For example, if sub-packet file M passes the sub-packet verification (i.e., is correctly received), the target load unit saves sub-packet file M and sends the second reception feedback message including the packet sequence number M to the load management device. If sub-packet file M+1 fails the sub-packet verification (i.e., is rejected), the target load unit discards sub-packet file M+1, stops receiving subsequent sub-packet files, and sends the second reception feedback message including the packet sequence number M to the load management device.

[0084] If the packet sequence number M in the second received feedback information remains unchanged for a continuous preset time, the load management device will start from the sub-packet file corresponding to the next packet sequence number (i.e., M+1) of the unchanged packet sequence number M and send the sub-packet files to the target load unit in ascending order at preset time intervals.

[0085] S123. After receiving each sub-package file that constitutes the software reconfiguration file, the target payload unit responds to the operation instructions sent by the ground control station and starts the reconfiguration operation based on the software reconfiguration file.

[0086] In this way, the target payload can be quickly and effectively reconfigured using software reconfiguration files.

[0087] The payload software reconfiguration method for LEO satellites provided in this application divides the payload software reconfiguration into two stages: In the first stage, within the data transmission arc, the ground control station can fully utilize the uplink bandwidth of the space-to-ground data transmission link to rapidly upload the software reconfiguration file to the payload management device for storage. In the second stage, outside the data transmission arc, the payload management device can transmit the software reconfiguration file to the target payload unit via the payload internal interconnection bus to achieve software reconfiguration of the target payload unit. This method simplifies the software reconfiguration of the payload unit. Within the payload internal interconnection information transmission framework, it fully utilizes the uplink bandwidth of the space-to-ground data transmission link and the payload internal confirmation protocol, enabling the LEO satellite to complete the uploading of the software reconfiguration file within one data transmission arc and control the payload unit to switch to the new reconfiguration program in the next telemetry and control arc. Furthermore, the first feedback information sent by the payload management device to the ground control station and the second reception feedback information sent by the target payload unit to the payload management device can quickly determine whether the software reconfiguration file has been transmitted completely and accurately. It also allows for the retransmission of the software reconfiguration file even if it has not been transmitted accurately. In summary, this LEO satellite payload software reconfiguration method can effectively improve the efficiency and accuracy of LEO satellite payload software reconfiguration.

[0088] In some embodiments, the reconstructing process initiated by the target payload based on the software reconstructing file may fail. Figure 7 A flowchart illustrating the payload software reconfiguration method for LEO satellites provided in this application embodiment. Figure 3 ,like Figure 7 As shown, the payload software reconfiguration method for LEO satellites provided in this application embodiment may further include the following steps S124-S128: S124. If the target load fails to start the reconstruction operation based on the software reconstruction file, the load management device shall perform a third integrity check on the received file.

[0089] Specifically, the load management device can perform a third integrity check on the stored received file (i.e., the software reconstructed file) to further determine if there are any problems with the received file. The method for this third integrity check can be the same as the method for the second integrity check.

[0090] S125. If the received file fails the third integrity check, the load management device will receive each injected data frame of each sub-partition in the multiple sub-partitions retransmitted by the ground control station through the space-ground data transmission link, that is, re-execute the above S103.

[0091] S126. If the received file passes the third integrity verification, the load management device resends multiple sub-packet files to the target load unit in a preset time interval and in ascending order of packet sequence number.

[0092] In this case, it can be confirmed that the received file (i.e., the software reconfiguration file) stored by the payload management device is correct. Therefore, there is no need for the ground control station to transmit the software reconfiguration file back to the payload management device; the payload management device can directly resend the sub-packet file to the target payload unit, thereby improving the efficiency of payload software reconfiguration.

[0093] S127. If the target payload unit fails to start the reconstruction operation based on the software reconstruction file, it shall restore the operating state before the reconstruction operation was started, and re-receive the sub-packet files sent by the payload management device at preset time intervals and in ascending order of packet sequence number after the received file has passed the third integrity verification.

[0094] S128. The target payload unit performs sub-packet verification again based on the packet sequence number corresponding to the newly received sub-packet file, that is, it executes the above step S117 again.

[0095] In some embodiments, to verify the effectiveness and effect of the LEO satellite payload software reconfiguration method (hereinafter referred to as "this solution") provided in the above embodiments of this application, a comparative analysis is conducted on the payload software reconfiguration method using on-board payload management equipment through the payload command telemetry and control bus (hereinafter referred to as "related technology 1") and this solution.

[0096] Specifically, taking the software reconstruction file of the target payload as an example: the software reconstruction file of the SOC system has a file size of 15MB, containing approximately 130,000 injected data frames, divided into 64 sub-partitions according to a preset size. The data transmission rate of the space-to-ground data link is 1Mbps, and the injected frame error rate is 10%. -6 For example, the load management device sends injection data frames to the target load unit via the command and control line (CAN bus), with a maximum of 50 frames per second.

[0097] Using the method described in related technology 1, at an average upload rate of 50 frames per second, uploading all software reconstruction files would take at least 43 minutes. Considering potential instability in the space-to-ground data transmission link and errors causing injection frame transmission failures, ground control stations would need to confirm and retransmit data, requiring at least 6-8 data transmission segments. Due to the orbital characteristics of LEO satellites, a ground control station is only visible 2-3 times per day, meaning it would take 2-4 days to complete the uploading of all software reconstruction files, allowing the target payload to enter the new reconstruction program.

[0098] Using this method, at an average upload rate of 500 frames per second within a single data transmission arc, the upload of all partitions of the software reconstruction file can be completed in approximately 4.3 minutes. During the reconstruction process, if the data transmission link is unstable due to the first feedback information (e.g., partition bitmap), or if packet loss due to error rate causes incomplete partition reception, these partitions can be quickly added to the supplementary upload queue. Thus, after completing the upload of the entire software reconstruction file within this data transmission arc, sufficient time remains for multiple supplementary uploads. Outside of subsequent data transmission arcs, the payload management equipment can transfer (or relocate) the software reconstruction file to the payload unit. Even with a random 1% packet loss rate, the complete relocation of the software reconstruction file can still be completed within 90 minutes. Furthermore, in the next telemetry and control environment (telemetry and control arc), the target payload unit can respond to the running command and enter the new reconstruction program. Therefore, the overall time of the payload software reconstruction process is significantly shortened, and this method can effectively improve the efficiency and accuracy of LEO satellite payload software reconstruction.

[0099] This invention also provides an electronic device, which may include a display screen, a memory, and one or more processors. The display screen, memory, and processors are coupled. The memory stores computer program code, which includes computer instructions. When the processor executes the computer instructions, the electronic device can perform the various methods or steps executed in the above-described embodiments of the LEO satellite payload software reconfiguration method. Of course, this electronic device includes, but is not limited to, the aforementioned display screen, memory, and one or more processors.

[0100] This invention also provides a computer-readable storage medium for storing computer instructions for running the payload software reconfiguration method of the LEO satellite described above.

[0101] Through the above description of the embodiments, those skilled in the art can clearly understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

[0102] In the description of this invention, it should be understood that the terms "first" and "second" 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 as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this invention, "a plurality of" means at least two, such as two, three, etc., unless otherwise explicitly specified.

[0103] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., refer to specific features, structures, materials, or characteristics described in connection with that embodiment or example, which are included in at least one embodiment or example of the present invention. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of different embodiments or examples.

[0104] Similar parts between the embodiments provided in this application can be referred to mutually. The specific implementation methods provided above are only a few examples under the overall concept of this application and do not constitute a limitation on the scope of protection of this application. For those skilled in the art, any other implementation methods extended from the solution of this application without creative effort shall fall within the scope of protection of this application.

Claims

1. A payload software reconfiguration method for LEO satellites, characterized in that, The method, applied to payload management equipment installed in a LEO satellite, includes: The system receives each injected data frame from each sub-partition sent by the ground control station via the space-ground data transmission link. Each injected data frame includes a corresponding area code and an intra-group offset number. The area code represents the sub-partition number where the injected data frame is located, and the intra-group offset number represents the position of the injected data frame within its sub-partition. Each sub-partition is obtained by the ground control station partitioning and framing the software reconstruction file of the target payload unit according to a preset size. Each sub-partition includes multiple injected data frames. Perform a first integrity check on the injected data frame; If the injected data frame fails the first integrity check, the injected data frame is discarded. If the injected data frame passes the first integrity check, partition storage is determined based on the area number and group offset number corresponding to the injected data frame. Based on the number of injected data frames stored in the partition, a first feedback information is sent to the ground control station. The first feedback information is used to characterize the reception status of injected data frames in each sub-partition. The injected data frames stored in the partition are integrated to obtain the received file, and the received file is subjected to a second integrity check. If the received file passes the second integrity check, the received file is determined to be the software reconstruction file, and the software reconstruction file is divided into multiple sub-package files according to the preset package length, with each sub-package file corresponding to a package sequence number; In response to the upload command sent by the ground control station, the multiple sub-package files are sent to the target payload unit in a preset time interval and in ascending order of package number, so that the target payload unit can start reconstruction operation based on the software reconstruction file composed of the multiple sub-package files.

2. The method according to claim 1, characterized in that, The first feedback information is a partition bitmap, which includes multiple grids, each grid corresponding to one of the multiple sub-partitions; sending the first feedback information to the ground control station based on the number of injected data frames stored in the partition includes: The number of injected data frames stored in the partition determines whether each injected data frame in each sub-partition is received. When each injected data frame in the sub-partition is received, the value of the grid corresponding to the sub-partition in the partition bitmap is set to 1, and the partition bitmap is sent to the ground control station. If an injected data frame is not received in a sub-partition, the value of the grid corresponding to the sub-partition in the partition bitmap is set to 0, and the partition bitmap is sent to the ground control station.

3. The method according to claim 1, characterized in that, The method further includes: If the received file fails the second integrity check, each injected data frame in the retransmission partition resent by the ground control station is received; the retransmission partition is the sub-partition in which the ground control station determines, based on the first feedback information, that not all injected data frames have been received. Based on the area number and group offset number corresponding to each injected data frame in the resending partition, the injected data frames stored in the partition are replaced and stored.

4. The method according to claim 1, characterized in that, The method further includes: The target payload unit receives second reception feedback information sent by the target payload unit. The second reception feedback information is used to characterize the target payload unit's reception status of the sub-packet file. The second reception feedback information includes: the packet sequence number corresponding to the sub-packet file. If the packet sequence number in the second received feedback information remains unchanged for a continuous preset time, starting from the sub-packet file corresponding to the next packet sequence number of the unchanged packet sequence number, the sub-packet files are sent to the target payload unit in ascending order of packet sequence number at the preset time interval until the target payload unit receives each sub-packet file that constitutes the software reconstruction file.

5. The method according to claim 1, characterized in that, The method further includes: If the target payload fails to initiate reconstruction based on the software reconstruction file, a third integrity check is performed on the received file. If the received file passes the third integrity check, the multiple sub-packet files are retransmitted to the target payload unit in ascending order of packet sequence number at the preset time interval.

6. A payload software reconfiguration method for LEO satellites, characterized in that, The method, applied to a single target payload mounted on a LEO satellite, includes: The load management device receives sub-packet files sent at preset time intervals in ascending order of packet sequence number. The sub-packet files are obtained by the load management device by dividing the software reconstruction file of the target load unit into packets according to the preset packet length. Each sub-packet file corresponds to a packet sequence number. Sub-package verification is performed based on the package sequence number corresponding to the sub-package file; If the sub-packet file passes the sub-packet verification, the sub-packet file is saved, and a second reception feedback information is sent to the load management device. The second reception feedback information is used to characterize the reception status of the sub-packet file, and the second reception feedback information includes: the packet sequence number corresponding to the sub-packet file; Upon receiving each sub-package file that constitutes the software reconfiguration file, the reconfiguration operation is initiated based on the software reconfiguration file in response to the operation command sent by the ground control station.

7. The method according to claim 6, characterized in that, The method further includes: If the sub-packet file fails the sub-packet verification, the sub-packet file is discarded, and a second reception feedback information is sent to the load management device. The second reception feedback information includes the packet sequence number corresponding to the previous received and saved sub-packet file. The system receives sub-packet files from the load management device starting with the sub-packet file corresponding to the packet sequence number determined based on the second received feedback information. The system then sends sub-packet files sequentially in ascending order of packet sequence number at the preset time interval. Sub-packet verification is performed based on the packet sequence number corresponding to the sub-packet file until each sub-packet file constituting the software reconstruction file is received.

8. The method according to claim 6, characterized in that, The method further includes: If the reconstruction operation fails to start based on the software reconstruction file, the system will restore the operating state before the reconstruction operation started and re-receive the sub-packet files sent by the receiving payload management device at the preset time interval in ascending order of packet sequence number after the receiving file has passed the third integrity verification.

9. A payload software reconfiguration method for LEO satellites, characterized in that, Applied to ground control stations, whereby data transmission between the ground control station and payload management equipment located in LEO satellites occurs via a space-to-ground data transmission link, the method includes: The software reconstruction file of the target payload single machine is partitioned, cut, and framed according to a preset size to determine multiple sub-partitions. Each sub-partition includes multiple injected data frames. Each injected data frame includes a corresponding zone number and an intra-group offset number. The zone number is used to represent the number of the sub-partition in which the injected data frame is located, and the intra-group offset number is used to represent the position of the injected data frame in its sub-partition. Within the data transmission arc, each injected data frame of each sub-partition in the plurality of sub-partitions is sent to the load management device through the ground-to-ground data transmission link.

10. The method according to claim 9, characterized in that, The method further includes: The first feedback information sent by the load management device is received, and the first feedback information is used to characterize the reception status of the injected data frame in each sub-partition; After each injected data frame of each sub-partition in the plurality of sub-partitions is sent to the payload management device, it is determined whether there is a resend partition based on the first feedback information. The resend partition is the sub-partition in which the injected data frame was not completely received. If the retransmission partition exists, each injected data frame in the retransmission partition is sent again to the load management device via the ground-to-ground data transmission link.

Images