Satellite software reconfiguration data transmission method and device, and electronic equipment

Abstract

The application provides a satellite software reconstruction data transmission method, device and electronic equipment, wherein the transmission method comprises the following steps: querying storage spaces of each load on the satellite, and generating a capacity list based on unoccupied storage spaces in each storage space; establishing a logical link index for each unoccupied storage space indicated by the capacity list, wherein the logical link index indicates a storage sequence relationship of each unoccupied storage space; receiving target reconstruction data; and writing the target reconstruction data into the unoccupied storage spaces in the capacity list in sequence according to the logical link index. The application improves the transmission efficiency of the reconstruction data, and further improves the reconstruction efficiency of the satellite software.

Description

Technical Field

[0001] This invention relates primarily to the fields of embedded software and satellite communication technology, and particularly to a satellite software-based data transmission reconstruction method, apparatus, and electronic device. Background Technology

[0002] With the rapid development of satellite internet, communication payload functions are becoming increasingly complex, leading to an exponential increase in the scale of payload management information. However, existing on-orbit software update mechanisms are inefficient and struggle to support the practical needs of agile iteration. Particularly in core processes such as payload on-orbit reconfiguration and status data uploading, data transmission efficiency significantly impacts software reconfiguration efficiency.

[0003] Limited by onboard resources, dynamic bit error rate, and limited space-to-ground communication window, existing reconstruction data / reconstruction file transmission schemes suffer from the following drawbacks: 1. Discretized storage: Onboard MRAM (Magnetoresistive Random Access Memory) has limited and discrete storage space, making it impossible to load large reconstruction files into the communication buffer all at once. Due to the fixed hardware functionality, expansion cannot be achieved by replacing hardware, severely restricting the on-orbit update capability of the software. 2. Transmission overlay risk: Existing communication areas are typically limited to a single location and use interrupt-based interaction. When the ground station's transmission rate exceeds the carrier management unit's read rate, new data will directly overwrite unread old data, leading to the failure of the entire reconstruction process. 3. Difficult engineering implementation: Existing solutions typically require deep reconstruction of the original carrier management software's main code, resulting in long development cycles, high engineering risks, and difficulty in rapid and stable deployment in engineering practice. 4. Limitations of Arc Segment Planning: Current arc segment planning for low-Earth orbit satellite reconstruction missions relies entirely on manual pre-planning based on ephemeris data from the ground, which cannot adapt to dynamic changes in the on-orbit link (such as ionospheric scintillation, elevation fluctuations, and ground station resource conflicts). This static planning method is highly susceptible to problems such as incomplete transmission of single arc segments, errors in splicing multi-arc segment data, and even complete failure of the reconstruction mission.

[0004] As can be seen from the above, there is an urgent need for an efficient on-orbit reconfiguration mechanism for payload software that can adapt to on-board resource constraints, overcome transmission coverage risks, simplify engineering implementation, and dynamically adapt to link changes. Summary of the Invention

[0005] The technical problem to be solved by the present invention is to provide a satellite software reconstruction data transmission method, apparatus and electronic device to improve the transmission efficiency of reconstructed data, thereby improving the reconstruction efficiency of satellite software.

[0006] To address the aforementioned technical problems, in a first aspect, the present invention provides a satellite software reconstructing data transmission method, comprising: querying the storage space of each payload on the satellite, and generating a capacity list based on the unoccupied storage space in each of the storage spaces; establishing logical link indexes for each unoccupied storage space indicated by the capacity list, wherein the logical link indexes indicate the storage order of each unoccupied storage space; receiving target reconstruction data; and sequentially writing the target reconstruction data into the unoccupied storage space in the capacity list according to the logical link indexes.

[0007] Optionally, receiving the target reconstructed data includes: receiving first reconstructed data; decompressing the first reconstructed data to form second reconstructed data; performing a CRC check on the second reconstructed data and the initial reconstructed data to determine whether the correct target reconstructed data has been obtained, wherein the initial reconstructed data is predetermined software reconstructed data; if the CRC check passes, the second reconstructed data is the target reconstructed data.

[0008] Optionally, receiving the target reconstructed data includes: receiving first reconstructed data and identifying that the first reconstructed data is uncompressed data; performing a CRC check on the first reconstructed data and the initial reconstructed data to determine whether the correct target reconstructed data has been obtained, wherein the initial reconstructed data is predetermined software reconstructed data; if the CRC check passes, the first reconstructed data is the target reconstructed data.

[0009] Optionally, the method further includes: if the CRC check fails, indicating that the satellite has not successfully received the target reconstruction data.

[0010] Optionally, the method further includes: identifying the file type of the target reconstruction data; writing the target reconstruction data into the unoccupied storage space in the capacity list according to the logical link index further includes: preferentially writing the target reconstruction data into the unoccupied storage space corresponding to the file type.

[0011] Optionally, the method further includes: predicting the transmission time of the target reconstructed data based on the data volume of the target reconstructed data, matching a communication arc that satisfies the transmission time based on the transmission time, and receiving the target reconstructed data within the matched communication arc.

[0012] Optionally, the method further includes: monitoring whether the carrier management unit in the satellite reads the target reconstruction data, or obtaining indication information on whether the carrier management unit has read the target reconstruction data, and releasing the storage space corresponding to the read target reconstruction data if the carrier management unit has read the target reconstruction data.

[0013] Secondly, the present invention provides a satellite software reconstructing data transmission device, comprising: a query module configured to query the storage space of each payload on the satellite and generate a capacity list based on the unoccupied storage space in each of the storage spaces; a linking module configured to establish logical link indexes for each unoccupied storage space indicated by the capacity list, the logical link indexes indicating the storage order of each unoccupied storage space; a receiving module configured to receive target reconstructing data; and a storage module configured to sequentially write the target reconstructing data into the unoccupied storage space in the capacity list according to the logical link indexes.

[0014] Thirdly, the present invention provides an electronic device comprising: a processor and a memory, the memory storing a program or instructions running on the processor, the program or instructions being executed by the processor to implement the steps of the satellite software reconfiguration data transmission method as described in the first aspect.

[0015] Fourthly, the present invention provides a readable storage medium on which a program or instructions are stored, which, when executed by a processor, implement the steps of the satellite software reconstructing data transmission method as described in the first aspect.

[0016] Compared with existing technologies, this invention has the following advantages: By querying the storage space of each payload on the satellite and generating a capacity list based on the unoccupied storage space in each storage space, and then linking the unoccupied storage spaces into a logically contiguous storage space, a logical link index is established, achieving end-to-end storage structure optimization. Without modifying or being unable to modify the hardware, it maximizes the utilization of the discrete storage space on the satellite, breaks through the storage bottleneck of software upgrades and service reconstruction, provides more storage space for reconstructed data, significantly improves the success rate and efficiency of reconstructed data transmission, and thus improves the reconstruction efficiency of satellite software. Attached Figure Description

[0017] The accompanying drawings are included to provide a further understanding of this application; they are incorporated into and constitute a part of this application. The drawings illustrate embodiments of this application and, together with this specification, serve to explain the principles of this application. In the drawings: Figure 1 This is a flowchart illustrating a satellite software reconstruction data transmission method according to an embodiment of the present invention; Figure 2 This is a schematic diagram comparing the discrete storage space and the linked storage space in one embodiment of the present invention; Figure 3 This is a schematic diagram of the target reconstruction data writing process in one embodiment of the present invention; Figure 4 This is a schematic diagram of compressed reconstructed data processing in one embodiment of the present invention; Figure 5 This is a schematic diagram of uncompressed reconstructed data processing in one embodiment of the present invention; Figure 6 This is a schematic diagram of the transmission rate prediction process in one embodiment of the present invention; Figure 7 This is a schematic diagram showing the size occupied by compressed data and uncompressed data in one embodiment of the present invention; Figure 8 This is a schematic diagram of the structure of a satellite software reconstructing data transmission device according to an embodiment of the present invention; Figure 9 This is a schematic diagram of an electronic device according to an embodiment of the present invention. Detailed Implementation

[0018] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are merely some examples or embodiments of this application. For those skilled in the art, these drawings can be applied to other similar scenarios without creative effort. Unless obvious from the context or otherwise specified, the same reference numerals in the drawings represent the same structures or operations.

[0019] As indicated in this application and claims, unless the context clearly indicates otherwise, the words "a," "an," "an," and / or "the" are not specifically singular and may include plural forms. Generally speaking, the terms "comprising" and "including" only indicate the inclusion of explicitly identified steps and elements, which do not constitute an exclusive list, and the method or apparatus may also include other steps or elements.

[0020] Furthermore, it should be noted that the use of terms such as "first" and "second" to define components is merely for the purpose of distinguishing the corresponding components. Unless otherwise stated, these terms have no special meaning and therefore should not be construed as limiting the scope of protection of this application. In addition, although the terminology used in this application is selected from commonly known and used terms, some terms mentioned in this application's specification may have been chosen by the applicant according to his or her judgment, and their detailed meanings are explained in the relevant sections of this description. Moreover, this application should be understood not only through the actual terms used, but also through the meaning implied by each term.

[0021] Flowcharts are used in this application to illustrate the operations performed according to embodiments of this application. It should be understood that the preceding or following operations are not necessarily performed in exact order. Instead, various steps can be processed in reverse order or simultaneously. Furthermore, other operations may be added to these processes, or one or more steps may be removed from them.

[0022] refer to Figure 1 As shown, this embodiment provides a satellite software reconstructing data transmission method. Method 100 includes: S110, querying the storage space of each payload on the satellite, and generating a capacity list based on the unoccupied storage space in each of the storage spaces, where the unoccupied storage space can also be called the remaining storage space or available storage space; S120, establishing a logical link index for each unoccupied storage space indicated by the capacity list, where the logical link index indicates the storage order of each unoccupied storage space; S130, receiving target reconstruction data; S140, writing the target reconstruction data sequentially into the unoccupied storage space in the capacity list according to the logical link index.

[0023] Traditional satellite payload software or configuration data typically uses pre-planned fixed storage addresses. For example, the service storage block stores service tables, the parameter storage block stores payload parameters, the upload storage block stores binary files of reconstructed data, and the default storage block stores backups of the initial software version. During the process of uploading reconstructed data or files from the ground station to the satellite, the specific implementation involves the satellite service system first receiving the reconstructed data, then transferring it to the communication area between the satellite service system and the corresponding payload upgrade. The payload management unit then retrieves the reconstructed data from the communication area. Only after all the reconstructed data has been completely retrieved can subsequent software reconstructing operations be performed. However, current engineering systems only have one communication area with limited capacity, and interaction is achieved through interrupts, resulting in a data transmission rate bottleneck between the satellite service system and the payload management unit. This bottleneck limits the communication rate between the ground station and the satellite because reconstructed data is generally large. For example, if a piece of reconstructed data is 500KB, the ground station needs to split it into large data packets before sending it, such as sending one large data packet per second (1KB per second). After receiving the large data packets, the satellite service computer will transfer them to the communication area and wait for the payload management unit to read the data. When the communication rate between the ground station and the satellite is too high, meaning too many data packets arrive, the new data is transferred to the communication area by the satellite computer before the existing content has been retrieved by the carrier unit, causing the original content to be overwritten.

[0024] To fully utilize the storage space of each payload on the satellite and effectively improve the data transmission rate between the payload management unit and the satellite service system, reference Figure 2 As shown, the numbers here are 1, 2, ..., n. Figure 2 The actual storage above corresponds to the discrete, unused storage spaces of each payload on the satellite, namely M1, M2, ..., Mn KB. These discrete storage spaces are linked into a logically contiguous storage space in the program, i.e., linked storage, such as... Figure 2As shown below, this linked storage does not require the storage space to be physically contiguous; it only needs to be logically organized sequentially. Reconstructed data can be stored in any available storage space, linked together using a linked list index, block number, next block pointer, and block verification information. This allows for the utilization of different storage spaces (blocks). This embodiment links discrete storage spaces into a logically contiguous block, enabling dynamic adjustment of data transmission and reception rates through the linked storage state. Under conditions of limited satellite-to-ground windows, this significantly improves data transmission success rate and efficiency, increases the upper limit of communication rates between the ground station and the satellite, reduces or eliminates data loss due to buffer overflows, and improves the transmission efficiency of reconstructed data, thereby enhancing the reconstruction efficiency of satellite software.

[0025] For example, refer to Figure 3 As shown, one implementation method for storing reconstructed data is as follows: First, the available storage spaces Mi, i=1,2,...,n for the onboard payload are identified, and a capacity list is generated based on these storage spaces. The capacity list records the "occupiable attributes" of the storage spaces corresponding to each payload function in the reconstruction task, determines the location where the target reconstructed data should be written, and how much storage space is needed for storage. Furthermore, the capacity list is used to uniformly catalog multiple discrete storage spaces on the satellite, ensuring that the target reconstructed data has a set of available storage spaces before being written. The mapping relationship between the target reconstructed data and storage spaces is determined based on the capacity list. When any remaining storage space is insufficient, multiple remaining storage spaces are chained together as candidate nodes to continue storing the target reconstructed data in a logically continuous but storage-discrete manner until the target reconstructed data is completely saved. Second, it is confirmed whether the satellite service system has received the data. Third, if the satellite service system has received the data, the data is written to the current storage space Mi, i=1 according to the chained allocation strategy, and a logical link index is maintained synchronously. The logical link index describes how discrete storage spaces are chained into a logically continuous space, and the sequential relationship between the blocks of the target reconstructed data. After the current storage space is fully processed, the starting address of the next storage space is indicated, and the reconstructed data is written to the corresponding storage space one block at a time in the linked order. Finally, the management system or unit reads the target reconstructed data from the aforementioned storage.

[0026] In some embodiments, receiving target reconstructed data includes receiving first reconstructed data and decompressing the first reconstructed data to form second reconstructed data. A CRC check is performed between the second reconstructed data and the initial reconstructed data to determine whether the correct target reconstructed data has been obtained, wherein the initial reconstructed data is pre-determined software reconstructed data. If the CRC check passes, the second reconstructed data is the target reconstructed data. Furthermore, the method in this embodiment also includes identifying the file type of the target reconstructed data and preferentially writing the target reconstructed data to unoccupied storage space corresponding to the file type.

[0027] refer to Figure 4 As shown, one implementation method for storing reconstructed data is as follows: At the ground station, the file to be reconstructed, F0 (initial reconstructed data), is compressed using a compression algorithm, such as LZ4 compression, into a new file, F1 (first reconstructed data). The new file F1, the CRC checksum K0 of the file to be reconstructed, F0 (2 bytes long), and the file type TP (2 bytes long, used to determine the corresponding satellite payload memory area) are concatenated into a new binary file. This binary file is then sent to the satellite. Upon receiving the binary file, the satellite splits it into the compressed reconstructed file F1, the CRC checksum K0 of the file to be reconstructed, and the file type TP. After this, the compressed reconstructed file F1 is decompressed, such as using LZ4 decompression. Decompression is the inverse of compression, resulting in the decompressed file F2. After obtaining file F2, its CRC checksum K1 (2 bytes in length) is calculated and compared with the CRC checksum K0 of the file to be reconstructed, F0. If K1 = K0, it means the satellite has successfully decompressed and obtained the correct file to be reconstructed, F0. Then, the decompressed reconstructed file F2 is copied to the corresponding payload's memory area according to the file type TP to be reconstructed. If K1 ≠ K0, it means the satellite has not successfully decompressed and obtained the correct file to be reconstructed, F0, and the reconstruction process ends.

[0028] In some embodiments, receiving target reconstructed data includes: receiving first reconstructed data, identifying the first reconstructed data as uncompressed data, and performing a CRC check between the first reconstructed data and initial reconstructed data to determine whether the correct target reconstructed data has been obtained, wherein the initial reconstructed data is pre-determined software reconstructed data. If the CRC check passes, the first reconstructed data is the target reconstructed data. Furthermore, the method in this embodiment also includes identifying the file type of the target reconstructed data and preferentially writing the target reconstructed data into unoccupied storage space corresponding to the file type.

[0029] refer to Figure 5As shown, for uncompressed reconstructed data, the file to be reconstructed, F0, its CRC checksum (2 bytes), and its file type, TP (2 bytes, used to determine the corresponding satellite payload memory area), are concatenated into a new binary file. Correspondingly, after receiving this binary file, the satellite splits it into the file to be reconstructed, F0, its CRC checksum, K0, and its file type, TP. Then, the satellite calculates the CRC checksum K2 (2 bytes) of the received file to be reconstructed, and compares it with the CRC checksum K0. If K0 = K2, the satellite has successfully received the correct file to be reconstructed, F0, and stores it in the corresponding payload memory area according to its file type, TP. If K0 ≠ K2, the satellite has not successfully received the correct file to be reconstructed, F0, and the reconstruction process ends.

[0030] For example, assuming the target reconstruction data size is 600KB, the on-board storage space is affected by the new function. Since only 256KB of the upper storage area is available for reconstruction, it cannot accommodate 600KB of reconstruction data. Referring to Table 1, the capacity list can be recorded as shown in Table 2, and the corresponding logical link index is shown in Table 3.

[0031] Table 1

[0032] Table 2

[0033] Table 3

[0034] This embodiment's method is compatible with uncompressed reconstructed data, requires no modification to the original process, has controllable risks, and offers high scalability and adaptability. Furthermore, processes with and without compressed reconstructed data can be seamlessly switched, and automatic degradation to the original mode is implemented in case of failure. For example, if decompression fails, the original file is transmitted directly without compression; if the received data's CRC check fails, automatic degradation to the original mode is achieved; and if the satellite's current software version is incompatible, compatibility with older versions is ensured, automatically reverting to the original mode. Therefore, this embodiment's method ensures that the reconstructing task can be executed under any operating conditions, significantly improving the fault tolerance and mission continuity of the satellite system.

[0035] In some embodiments, the data reconstruction method further includes: indicating that the satellite has not successfully received the target reconstruction data if the CRC check fails. For example, if the satellite fails to receive the target reconstruction data, the status word of the corresponding data block can be marked as "reception invalid." Based on this mark, the satellite platform will no longer send an acknowledgment of the data block to the uplink software and will continue to wait for ground retransmission within the current communication arc's receiving window.

[0036] In some embodiments, the method further includes: predicting the transmission time of the target reconstructed data based on the data volume of the target reconstructed data; matching communication arcs that meet the transmission time requirements based on the transmission time; and receiving the target reconstructed data within the matched communication arcs. This achieves fully automated on-orbit reconstructing without ground-based manual intervention, allowing the satellite to autonomously complete the communication arc planning task.

[0037] In one implementation, historical actual transmission rates are input into a prediction model to predict the effective transmission rate for future consecutive time steps. This is combined with factors such as software-reconstructed data volume, compression status, high-speed / compatible transmission protocols, FIFO buffering, linked storage, checksum retransmission, and on-board resource constraints to automatically predict the reconstructed data transmission time. Based on this transmission time, an on-orbit reconstructed transmission plan and instruction sequence are generated. (Reference) Figure 6 As shown, the prediction model may include a normalization layer, a fully connected layer, a positional encoding layer, a grouped convolutional layer, a nonlinear activation layer, and a normalized output layer. The normalization layer eliminates differences in rate dimensions; the fully connected layer learns the global correlation between historical rates; the positional encoding layer preserves the temporal order of the rate sequence; the grouped convolutional layer extracts short-period fluctuations and long-period trends; the nonlinear activation layer fits the impact of factors such as link quality, protocol mode, buffer status, and processing load on the rate; and the normalized output layer outputs stable future rate predictions.

[0038] For example, the actual transmission rates during the existing reconstructed data transmission process are collected to form a historical rate sequence: v1, v2, ..., vt, ..., vN, where vt represents the actual effective transmission rate in the t-th time step, which can be calculated based on the amount of data successfully received and verified per unit time: vt = Qt / Δt, where Qt is the amount of data successfully received and verified in the t-th time step, and Δt is the statistical period, typically 1 second or 10 seconds, depending on the desired time granularity of the system. If the current task is the first reconstructed transmission and there is no historical actual rate yet, the initial real-time transmission rate can be used for prediction. Specifically, the real-time effective transmission rate is statistically analyzed shortly after the start of transmission as the initial rate sequence, or the nominal effective rate under the current protocol mode is used as the initial value. After actual rate data is generated during the transmission process, it is then used as new historical rate data to update the prediction model.

[0039] Then, the historical rate sequence or the initial real-time rate sequence is input into the prediction model to predict the effective transmission rate for subsequent time steps: vN+1, vN+2, ..., vN+M. After obtaining the predicted future rate values, the transmission duration is inferred based on the target reconstructed data size. Let the target reconstructed data size be S. If compressed transmission is used, then S0 is the compressed data size; if uncompressed transmission is used, then S0 is the original data size. The total amount of data that can be transmitted at each future time step is accumulated.

[0040] When the following conditions are met:

[0041] The transmission time required to complete the target reconstruction data transmission is assumed to be M × Δt, where k = 1, 2, ..., M. Considering verification, retransmission, and security redundancy, the total required time can be further calculated: T_need = M × Δt + T_prepare + T_verify + T_write + T_margin Among them, T_prepare is the time for chain establishment, handshake, protocol negotiation and entering the reconstructed receiving mode, T_verify is the time for block verification and overall verification, T_write is the time for writing to the bet storage area or chain storage area, and T_margin is the time reserved for retransmission and exception handling.

[0042] Subsequently, candidate communication arcs are matched based on T_need. A candidate communication arc can be represented as: Pass_i = [Start_i, End_i]. The effective time for this communication arc to reconstruct the transmission is: T_available_i = End_i - Start_i - T_guard_i - T_other_i Where T_guard_i represents the protection time for link establishment, link release, and attitude stabilization, and T_other_i represents the time allocated to other tasks within this arc segment. If T_available_i >= T_need, then this communication arc segment can be used as the target to reconstruct the transmission arc segment. If a single communication arc segment cannot meet the transmission requirements, multiple communication arc segments can be selected for segmented transmission, and a corresponding file offset range can be allocated according to the amount of data that each communication arc segment can transmit, thus achieving breakpoint resumption.

[0043] Before determining candidate communication arcs, task conflict coordination can be performed to determine if there are communication resource conflicts or other on-orbit task conflicts for the chosen communication arc. For example, it can be determined whether the ground station and telemetry links are available, whether the link between the satellite computer and payload management software is available, and whether it conflicts with high-priority tasks such as staring or beam hopping communication services. If there are unadjustable high-priority conflicts, other communication arcs are selected as candidate communication arcs. If the conflicting task can be postponed, the conflicting task is adjusted and the communication arc is released. If the current reconfiguration task has a higher priority, the conflicting task is reassigned as a low-priority task.

[0044] After completing communication arc matching and task conflict coordination, a reconstructed transmission instruction sequence is automatically generated. This sequence may include entering reconstructed receiving mode, querying storage capacity, selecting a high-speed transmission protocol or a compatible transmission protocol, enabling FIFO caching, establishing a logical link index, sending target reconstructed data within the target communication arc, receiving data according to frame sequence number and file offset, writing to the above-mentioned storage area or chained storage area, performing block verification and overall verification, generating retransmission instructions when verification fails, generating breakpoint resume instructions during multi-arc transmission, and generating reconstructed execution instructions after verification passes.

[0045] Finally, the space service system and payload management software execute on-orbit reconfiguration data uploading within the target communication arc, following the generated instruction sequence. The actual effective rate generated during transmission continues to be recorded as new historical rate data, used for rate prediction in subsequent time steps and autonomous planning of communication arcs for subsequent reconfiguration tasks.

[0046] In some embodiments, the method further includes: monitoring whether the carrier management unit has read the target reconstruction data, or obtaining indication information indicating whether the carrier management unit has read the target reconstruction data; if the carrier management unit has read the target reconstruction data, releasing the storage space corresponding to the read target reconstruction data. For example, releasing the storage space corresponding to the read target reconstruction data, and simultaneously marking the storage space as "free" in the address mapping table for use by subsequently received new data blocks. If it is detected that the carrier management unit has not yet completed reading, maintaining the current locked state of the storage space, prohibiting the ground station from writing new data to the space, thereby fundamentally avoiding data contention and transmission overlay risks.

[0047] The following specific example further illustrates the method of this embodiment and its beneficial effects.

[0048] Assuming the file to be reconstructed, F0, has a data size of M bytes, and the compressed file to be reconstructed, F1, has a data size of N bytes, and the transmission rate is V bytes per second, then the transmission time for the file to be reconstructed, F0, is M / V seconds, and the transmission time for the compressed file to be reconstructed, F1, is N / V seconds. Therefore, under the same conditions, the transmission time depends only on the size of the file being transmitted. In this embodiment, the file to be reconstructed, F0, is compressed from M bytes to N bytes, which theoretically should reduce the transmission time by (M / V – N / V) / (M / V) = 1 - N / M. That is, the compression ratio of the compression algorithm multiplied by the transmission time of the default reconstruction scheme equals the reduction in transmission time.

[0049] Since the main time-consuming part of satellite payload reconstruction is file transfer, the reduced file transfer time in this embodiment can be directly considered as a reduction in reconstruction time. This is especially true when the number of waiting communication segments is reduced, significantly increasing reconstruction efficiency. For ease of analysis, let's assume each communication segment lasts L seconds and each waiting time lasts H seconds. Reconstruction requires ┌(M / V) / L┐ communication segments, corresponding to ┌(M / V) / L┐-1 waiting times. Therefore, the actual default reconstruction time can be expressed as (┌(M / V) / L┐-1). (L + H) + (M / V)%L. When the compression and reconstruction scheme reduces file transfer time, the required communication segments will also decrease accordingly. Assuming a reduction of U communication segments, the actual compression and reconstruction time can be expressed as (┌(M / V) / L┐ –U – 1). (L + H) + (N / V)%L. Therefore, the actual reduction in reconstruction time achieved by this solution should be U. (L + H) + (1-N / M) M / V.

[0050] Low-Earth orbit (LEO) satellites have short communication arcs, resulting in long file transfer times that require multiple communication arcs. When there are few ground stations or they are widely distributed, the intervals between communication arcs can be very long, significantly increasing the waiting time and operational risks of reconstruction. As described above, the reduction of U communication arcs is also related to the compression ratio of the compression algorithm; the greater the reduction in transmission time, the more U communication arcs can be reduced.

[0051] Figure 7In the file `app_usr_zg.bin`, file F0 is the file to be reconstructed, and `compressed_app_usr_zg.bin` is the compressed file F1. The compression rate is 1 - (166KB / 505KB) = 67.13%. Therefore, under the same conditions, this embodiment reduces file transfer time by approximately 67.13% compared to the scheme without compression, when reconstructing the data. For the file `app_usr_zg.bin`, 505KB is 505... 1024 bytes. For ease of calculation, let's assume a maximum transmission rate of 400 bytes per second, each communication arc lasting 6 minutes, and an interval of 2 hours between each communication arc. The actual reconstruction process takes longer than this, so the default reconstruction scheme requires 505 bytes to transmit. 1024 / 400 / 360 ≈ 4 communication arcs. The default reconstruction scheme takes 3 seconds. (360 + 7200) + (505 (1024 / 400)%360 = 22892.8 seconds. For the compressed_app_usr_zg.bin file, 166KB is equivalent to 166... 1024 bytes, the compressed reconstruction scheme requires 166 bytes for transmission. 1024 / 400 / 360 ≈ 2 communication arcs, therefore the compression and reconstruction scheme takes 1 second. (360 + 7200) + (166 1024 / 400)%360 = 7624.96 seconds.

[0052] This embodiment can also add a high-speed data transmission protocol to further reduce reconstruction time. For example, the data granularity of a single protocol processing session is expanded from approximately 500 bytes to approximately 1 KB. That is, the payload management software no longer performs a complete parsing, verification, writing, and acknowledgment process every 500 bytes received, but instead processes data in batches of 1 KB data units in high-speed mode. This reduces the number of data units corresponding to the same size of reconstructed data, decreases the number of protocol processing steps and acknowledgment waiting times, and improves the effective utilization of the link. To accommodate the 1 KB data unit processing method, a FIFO buffer mechanism is added to the payload management software. After the satellite computer sends reconstructed data via the 422 link, the payload management software first writes the received data into the FIFO buffer. The FIFO buffer is used to temporarily buffer continuously arriving data streams, and only after the buffered data reaches the data length specified by the high-speed protocol, or after receiving the end-of-frame marker, is the payload management software uniformly read, verify, and write the data to subsequent storage space. After adding the high-speed data transmission protocol, the transmission rate is capped at 3000 bytes per second. For the compressed_app_usr_zg.bin file, 166KB is equivalent to 166... 1024 bytes, the compressed reconstruction scheme requires 166 bytes for transmission. If 1024 / 3000 / 360 ≈ 1 communication arc, then the compression and reconstruction scheme takes 0 seconds. (360 + 7200) + (166 1024 / 400)%360 = 56.66 seconds.

[0053] refer to Figure 8 As shown, this embodiment provides a satellite software reconfiguration data transmission device. The device 800 mainly includes: a query module 810, configured to query the storage space of each payload on the satellite and generate a capacity list based on the unoccupied storage space in each of the storage spaces; a linking module 820, configured to establish logical link indexes for each unoccupied storage space indicated by the capacity list, the logical link indexes indicating the storage order of each unoccupied storage space; a receiving module 830, configured to receive target reconfiguration data; and a storage module 840, configured to write the target reconfiguration data sequentially into the unoccupied storage space in the capacity list according to the logical link indexes.

[0054] In some embodiments, receiving target reconstruction data includes: receiving first reconstruction data, decompressing the first reconstruction data to form second reconstruction data; performing a CRC check on the second reconstruction data and the initial reconstruction data to determine whether the correct target reconstruction data has been obtained, wherein the initial reconstruction data is predetermined software reconstruction data; if the CRC check passes, the second reconstruction data is the target reconstruction data.

[0055] In some embodiments, receiving target reconstructed data includes: receiving first reconstructed data and identifying that the first reconstructed data is uncompressed data; performing a CRC check between the first reconstructed data and the initial reconstructed data to determine whether the correct target reconstructed data has been obtained, wherein the initial reconstructed data is predetermined software reconstructed data; and if the CRC check passes, the first reconstructed data is the target reconstructed data.

[0056] In some embodiments, the apparatus 800 further includes an indication module configured to indicate that the satellite has not successfully received the target reconstruction data if the CRC check fails.

[0057] In some embodiments, the apparatus 800 further includes an identification module configured to identify the file type of the target reconstruction data and preferentially write the target reconstruction data into unoccupied storage space of the corresponding file type.

[0058] In some embodiments, the apparatus 800 further includes a prediction module configured to predict the transmission time of the target reconstructed data based on the amount of data in the target reconstructed data, and to receive the target reconstructed data within the matched communication arc based on the transmission time matching.

[0059] In some embodiments, the device 800 further includes a detection module configured to monitor whether the carrier unit reads the target reconstruction data, or to obtain indication information as to whether the carrier unit has read the target reconstruction data, and to release the storage space corresponding to the read target reconstruction data if the carrier unit has read the target reconstruction data.

[0060] For details of other operations performed by each module in this embodiment, please refer to the foregoing embodiments, which will not be elaborated here.

[0061] This embodiment's device queries the storage space of each payload on the satellite, generates a capacity list based on the unoccupied storage space in each storage space, and then links the unoccupied storage spaces into a logically contiguous storage space, establishing a logical link index to achieve end-to-end storage structure optimization. Without modifying or being able to modify the hardware, it maximizes the utilization of the discrete storage space on the satellite, breaking through the storage bottleneck of software upgrades and service reconstruction, giving reconstructed data more storage space, significantly improving the success rate and efficiency of reconstructed data transmission, and thus improving the reconstruction efficiency of satellite software.

[0062] The satellite software reconfiguration data transmission device in this application embodiment can be a device, or a component, integrated circuit, or chip in a terminal. The satellite software reconfiguration data transmission device in this application embodiment can be a device with an operating system. This operating system can be Android, iOS, or other possible operating systems; this application embodiment does not specifically limit its application.

[0063] This application also provides an electronic device, including: a memory for storing programs or instructions executable by a processor; and a processor for executing the programs or instructions to implement the various processes of the above-described satellite software reconstruction data transmission method embodiments, and achieving the same technical effects. To avoid repetition, it will not be described again here.

[0064] Figure 9 This is a schematic diagram of an electronic device according to an embodiment of the present invention. The electronic device 900 may include an internal communication bus 901, a processor 902, a read-only memory (ROM) 903, a random access memory (RAM) 904, and a communication port 905. When applied to a personal computer, the electronic device 900 may also include a hard disk 906. The internal communication bus 901 enables data communication between components of the electronic device 900. The processor 902 can perform judgments and issue prompts. In some embodiments, the processor 902 may consist of one or more processors. The communication port 905 enables data communication between the electronic device 900 and external devices. In some embodiments, the electronic device 900 can send and receive information and data from a network through the communication port 905. The electronic device 900 may also include different forms of program storage units and data storage units, such as the hard disk 906, the read-only memory (ROM) 903, and the random access memory (RAM) 904, capable of storing various data files used for computer processing and / or communication, as well as possible programs or instructions executed by the processor 902. The results processed by processor 902 are transmitted to the user equipment via communication port 905 and displayed on the user interface.

[0065] The above-described satellite software reconfiguration data transmission method can be implemented as a computer program, stored in the hard disk 906, and recorded in the processor 902 for execution, so as to implement any of the satellite software reconfiguration data transmission methods in this application.

[0066] This application also provides a readable storage medium storing a program or instructions. When the program or instructions are executed by a processor, they implement the various processes of the above-described satellite software reconstructing data transmission method embodiments and achieve the same technical effects. To avoid repetition, they will not be described again here.

[0067] The processor is the processor in the electronic device described in the above embodiments. The readable storage medium includes computer-readable storage media, such as computer read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0068] A computer-readable medium may contain a propagated data signal containing computer program code, for example, on baseband or as part of a carrier wave. This propagated signal may take various forms, including electromagnetic, optical, and so on, or suitable combinations thereof. A computer-readable medium can be any computer-readable medium other than a computer-readable storage medium, which can be connected to an instruction execution system, apparatus, or device to enable communication, propagation, or transmission of a program for use. The program code located on the computer-readable medium can be propagated through any suitable medium, including radio, cable, fiber optic cable, radio frequency signals, or similar media, or any combination of the above media.

[0069] For those skilled in the art, the above disclosure is merely illustrative and does not constitute a limitation of this application. Although not explicitly stated herein, those skilled in the art may make various modifications, improvements, and corrections to this application. Such modifications, improvements, and corrections are suggested in this application and therefore remain within the spirit and scope of the exemplary embodiments of this application.

[0070] In some embodiments, numbers describing the quantity of components and attributes are used. It should be understood that such numbers used in the description of embodiments are modified in some examples with the terms "approximately," "approximately," or "generally." Unless otherwise stated, "approximately," "approximately," or "generally" indicates that the numbers are allowed to vary by ±20%. Accordingly, in some embodiments, the numerical parameters used in the specification and claims are approximate values, which may be changed depending on the characteristics required by individual embodiments. In some embodiments, numerical parameters should take into account specified significant digits and employ a general method of digit reservation. Although the numerical ranges and parameters used to confirm their breadth of scope in some embodiments of this application are approximate values, in specific embodiments, such values ​​are set as precisely as feasible.

[0071] Although this application has been described with reference to specific embodiments, those skilled in the art should recognize that the above embodiments are only used to illustrate this application, and various equivalent changes or substitutions can be made without departing from the spirit of this application. Therefore, any changes or modifications to the above embodiments within the essential spirit of this application will fall within the scope of the claims of this application.

Claims

1. A satellite software-based method for reconstructing data transmission, characterized in that, include: Query the storage space of each payload on the satellite, and generate a capacity list based on the unoccupied storage space in each of the storage spaces; A logical link index is established for each unoccupied storage space indicated by the capacity list, and the logical link index indicates the storage order of each unoccupied storage space; Receive target reconstruction data; The target reconstruction data is written sequentially into the unoccupied storage space in the capacity list according to the logical link index.

2. The satellite software reconstruction data transmission method as described in claim 1, characterized in that, The received target reconstruction data includes: Receive the first reconstructed data and decompress it to form the second reconstructed data; The second reconstructed data and the initial reconstructed data are subjected to a CRC check to determine whether the correct target reconstructed data has been obtained, wherein the initial reconstructed data is the predetermined software reconstructed data; if the CRC check passes, the second reconstructed data is the target reconstructed data.

3. The satellite software reconstruction data transmission method as described in claim 1, characterized in that, The received target reconstruction data includes: Receive the first reconstructed data and identify that the first reconstructed data is uncompressed data; The first reconstructed data and the initial reconstructed data are subjected to a CRC check to determine whether the correct target reconstructed data has been obtained, wherein the initial reconstructed data is the predetermined software reconstructed data; if the CRC check passes, the first reconstructed data is the target reconstructed data.

4. The satellite software reconstruction data transmission method as described in claim 2 or 3, characterized in that, Also includes: If the CRC check fails, it indicates that the satellite has not successfully received the target reconstruction data.

5. The satellite software reconstruction data transmission method as described in claim 2 or 3, characterized in that, Also includes: Identify the file type of the target reconstructed data; Writing the target reconstruction data sequentially into the unoccupied storage space in the capacity list according to the logical link index also includes: prioritizing writing the target reconstruction data into the unoccupied storage space of the corresponding file type.

6. The satellite software reconstruction data transmission method as described in claim 1, characterized in that, Also includes: Based on the data volume of the target reconstructed data, the transmission time of the target reconstructed data is predicted. Based on the transmission time, a communication arc that satisfies the transmission time is matched, and the target reconstructed data is received within the matched communication arc.

7. The satellite software reconstruction data transmission method as described in claim 1, characterized in that, Also includes: The system monitors whether the carrier management unit in the monitoring satellite has read the target reconstruction data, or obtains indication information indicating whether the carrier management unit has read the target reconstruction data. If the carrier management unit has read the target reconstruction data, the system releases the storage space corresponding to the read target reconstruction data.

8. A satellite software reconstructing data transmission device, characterized in that, include: The query module is configured to query the storage space of each payload on the satellite and generate a capacity list based on the unoccupied storage space in each of the storage spaces. The linking module is configured to establish logical linking indexes for each unoccupied storage space indicated by the capacity list, the logical linking indexes indicating the storage order of each unoccupied storage space; The receiving module is configured to receive target reconstructed data. The storage module is configured to write the target reconstructed data sequentially into the unoccupied storage space in the capacity list according to the logical link index.

9. An electronic device, characterized in that, include: A processor and a memory, the memory storing a program or instructions that run on the processor, the program or instructions which, when executed by the processor, implement the steps of the satellite software reconfiguration data transmission method as described in any one of claims 1-7.

10. A readable storage medium, characterized in that, The readable storage medium stores a program or instructions that, when executed by a processor, implement the steps of the satellite software reconstructing data transmission method as described in any one of claims 1-7.

Images