Satellite payload version reconfiguration method and system

Abstract

The application provides a satellite payload version reconstruction method and system, comprising: uniformly numbering formats of data units of a payload reconstruction version to uniformly adapt to a satellite payload; and concurrently scheduling different packets between multiple interfaces according to the uniform numbering to send the payload reconstruction version to the satellite payload.

Description

Technical Field

[0001] This invention relates to the field of aerospace technology, and in particular to a method and system for reconstructing satellite payload versions. Background Technology

[0002] During satellite operation, payload software may require version upgrades or reconstruction due to feature expansion, defect fixing, parameter adjustment, algorithm updates, or changes in mission mode. Limited by air-to-ground link bandwidth, link error rates, payload interface types, payload processing capabilities, and storage resources, payload version reconstruction typically needs to be completed in stages over a considerable period, while ensuring the integrity of transmitted, cached, and written data. However, existing payload version reconstruction schemes are relatively inefficient and cannot meet the needs of large-scale mass-produced satellites. Summary of the Invention

[0003] The purpose of this invention is to provide a satellite payload version reconstruction method and system to solve the problem of low efficiency in existing satellite payload version reconstruction.

[0004] To address the aforementioned technical problems, this invention provides a satellite payload version reconstruction method, comprising: The data unit format of the payload reconstruction version will be standardized with a unified numbering system to ensure consistent adaptation to satellite payloads; and Different packets are concurrently scheduled across multiple interfaces based on the unified number to send the reconstructed payload version to the satellite payload.

[0005] Optionally, the satellite payload version reconstruction method further includes: With capability negotiation and available space feedback as prerequisites, the ground station provides verification of reconstruction feasibility, storage boundary, and version legality. By using a standardized data unit format with unified numbering and carrying the target write address or directory and file offset, it can uniformly adapt to both file system-less and file system-based payloads; and The system uses satellite software for cache management, packet loss detection, selective retransmission, and provides a unified state machine.

[0006] Optionally, the satellite payload version reconstruction method further includes: A three-level verification link is established, which includes ground source file data verification, satellite cache data verification, and payload write data verification. The retransmission direction is selected based on the consistency comparison of the three-level verification link. Perform partial verification, retransmission of abnormal sections, persistence of received bitmap and progress, and breakpoint resume to replace full file retransmission. A unified numbering space, window confirmation, and deduplication rules are shared among multiple low-speed interfaces. Based on the unified numbering space, window confirmation, and deduplication rules, different sub-packets are concurrently scheduled and interface fault migration and lossless degradation are performed.

[0007] Optionally, the satellite payload version reconstruction method further includes: Perform temporary area writing, full file verification before activation, start-up health check, old version retention, and failure rollback to maintain on-orbit safety; The system manages various satellite payloads through a unified message format and differentiated parameter configuration, and provides the unified message format and differentiated parameter configuration to software image external models, software image external parameters, and programmable logic configuration updates.

[0008] Optionally, in the satellite payload version reconstruction method, the ground station performs one or more of the following actions: Send a version reconstruction request for the target payload to the satellite software. The version reconstruction request includes the target payload identifier, the version number to be reconstructed, the file type, the total file length, the whole file verification algorithm, and the preferred interface. The feasibility and legality of the reconstruction are verified based on the target payload capacity, available space, size of the file to be reconstructed, version identifier, target hardware model, processor architecture, storage layout, and startup method; if the verification fails, the task is terminated and the reason for failure is output. The payload reconstruction version is divided into fixed-length or variable-length data units, each assigned a unique number, and configured with the total number of packets, target write address or target directory and file offset, effective data length, version data, and packet verification fields. Simultaneously, a full file verification value for the ground source file is generated. The data unit is transmitted via the air-to-ground link; if an anomaly occurs in the air-to-ground link, the corresponding data is retransmitted to the satellite software.

[0009] Optionally, in the satellite payload version reconstruction method, the satellite service software performs one or more of the following actions: Forward the version refactoring request to the target payload; Cache data and maintain a receive bitmap, sliding window or unified status table using packet number and total number of packets. Remove duplicate packets and generate selective retransmission requests for packets with check errors, reception timeouts or missing packets until a complete satellite-side reconstructed data is formed as a complete data unit. After all packets have been received, calculate the full file checksum of the Star Service cache data; The complete data unit is sent to the target payload in accordance with the unified payload reconfiguration protocol; After the target payload has written all the data into the complete data unit, a full file verification request is sent to the target payload. When the entire file verification fails, compare the entire file verification value of the space mission cache data with the entire file verification value of the ground source file; If the two are consistent, the anomaly is determined to be in the space-to-payload transmission or payload writing stage, and the corresponding data is resent to the target payload; If the two are inconsistent, the anomaly is determined to be in the air-to-ground link.

[0010] Optionally, in the satellite payload version reconstruction method, the target payload performs one or more of the following actions: Upon receiving a version refactoring request, the system returns refactoring capability information and available storage space information. For payloads without a file system, return the available memory address range, capacity, erase granularity, write granularity, and alignment rules; For loads with file systems, return the remaining space in the target directory, the maximum file size, and the filename rules. The reconstruction capability information also includes interface type, maximum data unit length, supported verification algorithms, and whether it supports breakpoint resume and version rollback; Verify the payload identifier, sub-packet number, target address range, effective length, and sub-packet verification value. Once verified, write the complete data unit of the reconstructed payload version to the target memory address or a temporary version file in the file system. Erase the flash memory in erase blocks and read back to verify after writing; Upon receiving a full file verification request, the target storage area or temporary version file is reread, and the full file verification value of the data is written based on one or more of the following computational payloads: CRC16, CRC32, SHA-256, hash check, or digital signature check. The result is then fed back to the ground station via the space service software. After the entire file verification passes, set the version flag to be enabled, and then reset or switch to the new version and perform a health check in the scheduled task window; If the health status is not reported within the preset time, the old version or a secure version will be restored. If the entire file verification fails and the failure is located in the air-to-ground link, the partial verification result is returned so that only the abnormal storage block, file segment or window is retransmitted.

[0011] Optionally, the satellite payload version reconstruction method further includes: The complete data unit includes a protocol identifier, target payload identifier, file identifier, packet number, total number of packets, target write information, effective length, version data, packet checksum, and status / extended field; The file system-less payload includes the target memory address; The file system payload includes the target directory, temporary filename, and file offset; When the target payload has at least two low-speed interfaces, the space service software will allocate data units with different sub-packet numbers to serial ports, CAN interfaces, network ports or other bus interfaces for concurrent transmission. All interfaces share a unified numbering space, confirmation window, and deduplication rules; When a certain interface experiences a series of errors, congestion, or interruption, unacknowledged data units can be migrated to other interfaces for lossless degradation.

[0012] Optionally, the satellite payload version reconstruction method further includes: The unified state machine for maintaining space-based software includes refactoring version requests, capability negotiation, data reception, data retransmission, payload writing, full file verification, version activation, anomaly recovery, and completion status. The reconstruction progress, current valid version, version to be enabled, and length written are saved in non-volatile storage area to support breakpoint resume after power failure, reset, or task interruption. The mission identifier, the complete checksum of the ground source file, the confirmed maximum consecutive packet number, the received bitmap digest, the length written, the temporary file status, and the rollback flag are stored in the non-volatile storage area. After a link interruption, satellite restart, or payload reset, all parties exchange mission identifiers and progress updates, and only transmit data units that are not yet completed or have failed verification to resume transmission from the point of interruption.

[0013] The present invention also provides a satellite payload version reconstruction system, comprising: The payload version reconstruction on the ground side is configured to uniformly number the data units of the payload reconstruction versions to ensure consistent adaptation to satellite payloads; and The payload version reconfiguration satellite service software is configured to concurrently schedule different sub-packets across multiple interfaces based on the unified number, so as to send the reconfigured payload version to the satellite payload.

[0014] In the satellite payload version reconstruction method and system provided by the present invention, by uniformly numbering the format of the data units of the payload reconstruction version, and concurrently scheduling different packets among multiple interfaces according to the uniform number, the satellite payload version reconstruction with unified interface, compatibility with payloads with and without file system can be achieved, and the transmission performance can be improved by concurrent use of multiple interfaces can be improved.

[0015] The inventors of this invention discovered through research that existing payload version reconstruction schemes typically require each payload to design its own upgrade protocol, packet format, storage and writing method, and exception handling mechanism. The interfaces and processes differ significantly between different payloads, necessitating the development of dedicated adaptation logic for each payload in the space operations software. This results in high software coupling, a large workload for verification, and poor reusability. Furthermore, some payloads require independent implementation of complex file reception, packet loss detection, and retransmission control, consuming limited processor, memory, and software resources.

[0016] Furthermore, existing solutions often struggle to quickly determine whether a fault lies in the ground-to-space link, the space-to-space buffer, the payload write failure, or the mission interruption. Some solutions only support retransmission of the entire file, failing to selectively retransmit by file number, resulting in low link utilization and long reconstruction times. For payloads with multiple low-speed interfaces, serial transmission via a single interface is typically selected, failing to fully utilize parallel transmission resources.

[0017] Therefore, there is a need for a satellite payload version reconstruction method that is simple to implement on the payload side, has a unified interface on the satellite service side, is compatible with payloads with and without file systems, supports hierarchical verification and fault location, and can improve transmission performance through concurrent use of multiple interfaces.

[0018] This invention centrally deploys cache management, packet loss detection, selective retransmission logic, and a unified state machine on both the spaceborne software and the ground side (ground station), abandoning the traditional distributed architecture where complex reception and retransmission control are implemented independently by a single payload. Simultaneously, it designs a unified numbered data unit format, embedding the target write address or directory and file offset fields. After parsing this format, the spaceborne software adapts it for direct address writing of payloads without a file system and directory offset writing of payloads with a file system. Based on this, a three-level verification link is constructed, covering the ground source file, spaceborne cached data, and the actual data written by the payload. The consistency comparison results are used to accurately locate abnormal links and trigger targeted retransmissions. This architecture significantly reduces the software size, processor resource consumption, and verification complexity on the payload side, achieving standardization and high reusability of the spaceborne interface. It not only uniformly supports both raw address storage and file system-based heterogeneous payloads but also effectively narrows the scope of fault diagnosis through a hierarchical integrity guarantee mechanism, greatly improving the reliability and transmission efficiency of on-orbit reconfiguration. It completely solves the core problems of inconsistent interfaces, complex payload implementation, difficulty in anomaly location, and low link utilization in existing technologies.

[0019] Given the limited and heterogeneous hardware resources of satellite payloads, if the payloads independently handle protocol parsing, packet retransmission, and storage management, the high coupling between individual protocols necessitates the development of extensive adaptation logic for the satellite service software, thus extending the verification cycle. By shifting the management functions of the control plane and data plane to the relatively resource-rich satellite service software and ground stations, and employing a centralized state machine and cache scheduling, protocol barriers between payloads can be eliminated. Simultaneously, a unified data unit, through abstract write pointers, shields the differences in the underlying storage media. The three-level verification link, based on hash comparison or cyclic redundancy check principles, verifies the data stream segment by segment. Once an inconsistency is detected, it can trace back to the specific breakpoint, thereby enabling precise retransmission path selection and invalid cache release based on existing technology.

[0020] This invention proposes a precondition verification and differentiated parameter configuration. Payload capacity negotiation and available storage space feedback are used as preconditions for reconstruction. The ground side, in conjunction with a configuration table, completes reconstruction feasibility assessment, storage boundary delineation, and version validity verification. Differential parameter configuration manages the target payload's address layout, filename rules, verification algorithms, reconstruction window, and error codes, while the core state machine remains unchanged. This avoids the risks of invalid versions being uploaded and storage space overflow, improving the automation level and batch management capabilities of ground operations and maintenance. New payload models can be quickly adapted or extended to model, parameter, and programmable logic configuration updates without modifying the core code, enhancing the system's maintainability and scalability. Based on the capability discovery mechanism and storage management in network communication, the ground side obtains the payload hardware specifications and cache availability before establishing a connection, performing pre-judgment and boundary constraints. The configuration table uses structured data mapping, abstracting the physical attributes of specific payloads into replaceable parameters. The state machine only relies on general parameters for execution, thus ensuring the stability of the core protocol stack.

[0021] This invention proposes local verification, bitmap management, and breakpoint resumption. It introduces a local verification mechanism and a received bitmap during data transmission, combined with a persistent reconstruction progress strategy. When the link is interrupted or the task is paused, the confirmed valid packet numbers and write positions are saved. During recovery, only missing or failed verification segments are retransmitted. This completely abandons the crude whole-file retransmission mode, significantly shortening fault recovery time, reducing the invalid occupation and energy consumption of air-to-ground links, and improving the success rate of long-duration reconstruction tasks. A bitmap data structure is used to record packet status, and session progress is solidified through persistent storage. During disconnection and reconnection, the bitmap is read and compared with the source file to identify unreceived or incorrectly verified data units. Based on the sliding window and selective acknowledgment protocol principles, only data blocks corresponding to missing sequence numbers are requested, thereby achieving breakpoint resumption and bandwidth optimization.

[0022] This invention proposes a multi-interface concurrent scheduling and fault migration mechanism. In scenarios with multiple low-speed physical interfaces, a concurrent scheduling strategy is implemented on the satellite service side to distribute different packets to each interface for parallel transmission. Each interface shares a unified data unit numbering space, acknowledgment window, and deduplication rules. When a single interface fails, untransmitted data is automatically migrated to a backup interface, achieving lossless degradation. This effectively aggregates the bandwidth of dispersed low-speed interfaces, breaks through the bottleneck of single link rate, and significantly improves the overall transmission speed. The interface switching process maintains the continuity and non-repetition of the data sequence, enhancing the transmission robustness in complex environments. Based on the principles of multi-queue scheduling and load balancing, the satellite service software maintains a global numbering pool and dynamically allocates packet tasks according to interface availability. The receiving end relies on the unified numbering for reassembly and deduplication. When the bit error rate of a certain interface exceeds the standard or is interrupted, the scheduler shifts the queue pointer to other available links, thereby avoiding global reconstruction failure caused by a single point of failure.

[0023] This invention proposes a temporary area writing, pre-activation verification, and secure rollback mechanism. Reconstructed data is first written to a temporary storage area. After the entire file is written, a full pre-activation verification and startup health check are performed. If the verification passes, the running pointer is switched to the new version, while the old version's data is fully preserved. If the startup health check fails or an abnormal operation occurs, a rollback mechanism is immediately triggered to restore the old version. This constructs a secure sandbox for version upgrades, effectively isolating the impact of erroneous data on the current operating system, significantly reducing the on-orbit risk of payload function failure due to version defects or write interference, and ensuring the continuity of core satellite services. A dual-partition mirror update or shadow update strategy is adopted, with the new version completed in an isolated area to ensure its integrity and executability. The health check confirms the operating environment compatibility by injecting standard test instructions into the new software and comparing the feedback status. The rollback operation, based on the pointer redirection principle, restores the system boot address to the old version's verification area, thereby ensuring the security of the reconstruction process. Attached Figure Description

[0024] Figure 1 This is a schematic diagram of the overall process of the satellite payload version reconstruction method in one embodiment of the present invention; Figure 2 This is a schematic diagram illustrating the interaction between the ground station, satellite service software, and target payload system in the overall architecture of the satellite payload version reconstruction system according to one embodiment of the present invention. Figure 3 This is a schematic diagram illustrating the reconstruction of data unit format using a satellite payload version reconstruction method according to an embodiment of the present invention; Figure 4 This is a schematic diagram of multi-interface concurrent transmission of a satellite payload version reconstruction method according to an embodiment of the present invention; Figure 5 This is a schematic diagram of the verification anomaly handling and retransmission decision-making process of the satellite payload version reconstruction method in one embodiment of the present invention; Figure labeling: 100—Ground station; 200—Star Service Software; 210—Refactoring Management Module; 220—Cache Module; 230—Interface Adaptation Module; 240—Integrity Detection Module; 250—Status Management Module; 300—Target payload; 310—Reconstruction command processing module; 320—Data verification module; 330—Storage writing module; 340—Version status module; F01~F10—Data unit fields; I01—Serial port transmission channel; I02—CAN transmission channel; I03—Network port transmission channel; D01—Payload file verification and judgment node; D02—Star service cache and ground source file consistency judgment node. Detailed Implementation

[0025] In this invention, the various embodiments are merely intended to illustrate the solutions of the invention and should not be construed as limiting.

[0026] It should also be noted that within the scope of this invention, the terms "same", "equal", and "equal to" do not mean that the two values ​​are absolutely equal, but allow for a certain reasonable error. In other words, the terms also cover "substantially the same", "substantially equal", and "substantially equal to".

[0027] Furthermore, the numbering of the steps in the methods of the present invention does not limit the execution order of the method steps. Unless otherwise specified, the method steps may be executed in different orders.

[0028] The satellite payload version reconstruction method and system proposed in this invention will be further described in detail below with reference to the accompanying drawings and specific embodiments. The advantages and features of this invention will become clearer from the following description and claims. It should be noted that the drawings are all in a very simplified form and use non-precise proportions, and are only used to facilitate and clarify the illustration of the embodiments of this invention.

[0029] In this invention, the modules of the system according to the invention can be implemented using software, hardware, firmware, or a combination thereof. When a module is implemented using software, its function can be implemented through computer program flow. For example, the module can be implemented using code segments (such as code segments in languages ​​like C and C++) stored in a storage device (such as a hard disk, memory, etc.), wherein the corresponding function of the module can be implemented when the code segment is executed by a processor. When a module is implemented using hardware, its function can be implemented by setting a corresponding hardware structure. For example, the module's function can be implemented by hardware programming a programmable device such as a field-programmable gate array (FPGA), or by designing an application-specific integrated circuit (ASIC) that includes multiple transistors, resistors, capacitors, and other electronic devices. When a module is implemented using firmware, the module's function can be written into a read-only memory such as an EPROM or EEPROM in the form of program code, and the corresponding function of the module can be implemented when the program code is executed by a processor. In addition, some functions of the module may need to be implemented by separate hardware or by working in cooperation with the hardware. For example, the detection function is implemented by a corresponding sensor (such as a proximity sensor, accelerometer, gyroscope, etc.), the signal transmission function is implemented by a corresponding communication device (such as a Bluetooth device, infrared communication device, baseband communication device, Wi-Fi communication device, etc.), the output function is implemented by a corresponding output device (such as a display, speaker, etc.), and so on.

[0030] The purpose of this invention is to provide a satellite payload version reconstruction method and system to solve the problem of low efficiency in existing satellite payload version reconstruction.

[0031] Specifically, this invention aims to address technical issues such as inconsistent reconstructing interfaces for different payload versions, complex payload-side implementation, low transmission efficiency of air-to-ground and intra-satellite links, coarse handling of error and missing packets, difficulty in locating abnormal locations, high recovery costs after mission interruption, and the inability to aggregate bandwidth from multiple low-speed interfaces. At the same time, it also takes into account the unified adaptation of payloads without a file system and payloads with a file system, version legality verification, rollback upon startup failure, and on-orbit maintenance safety.

[0032] To achieve the above objectives, the present invention provides a satellite payload version reconstruction system, including a payload version reconstruction ground side (hereinafter referred to as ground station or ground side) and a payload version reconstruction satellite service software side (hereinafter referred to as satellite service software or satellite service side). Figure 2 The overall architecture of a satellite payload version reconstruction system according to an embodiment of the present invention is shown, such as... Figure 2 As shown, the satellite payload version reconstruction system is a unified version reconstruction system executed collaboratively by ground station 100, satellite service software 200, and target payload 300. Figure 2 The paper also illustrates the interaction between a ground station 100, satellite service software 200, target payload 300, and their functional modules 210-250 and 310-340 in a satellite payload version reconstruction system according to one embodiment of the present invention. The satellite service software 200 includes a reconstruction management module 210, a caching module 220, an interface adaptation module 230, an integrity detection module 240, and a status management module 250. The target payload 300 includes a reconstruction command processing module 310, a data verification module 320, a storage writing module 330, and a version status module 340. Differences between payloads are encapsulated as capability parameters and configuration parameters, and the satellite service software manages different payloads through a unified message format and a unified state machine.

[0033] Embodiments of the present invention also provide a satellite payload version reconstruction method. Figure 1 The overall flow of a satellite payload version reconstruction method according to an embodiment of the present invention is shown, as follows: Figure 1 As shown, the specific steps S101 to S109 are as follows: S101, the ground station sends a version reconstruction request for the target payload to the satellite service software. The request may include information such as the target payload identifier, the version number to be reconstructed, the file type, the total file length, the whole file verification algorithm, and the preferred interface.

[0034] In step S102, the space service software forwards the request to the target payload; the target payload returns reconstruction capability information and available storage space information. For payloads without a file system, it returns the available memory address range, capacity, erase granularity, write granularity, and alignment rules; for payloads with a file system, it returns the remaining space in the target directory, maximum file size, and filename rules. Reconstruction capability information may also include interface type, maximum data unit length, supported verification algorithms, and whether breakpoint resumption and version rollback are supported.

[0035] S103, the ground station performs feasibility and legality checks on the target payload capacity, available space, size of the file to be reconstructed, version identifier, target hardware model, processor architecture, storage layout and startup method; if the conditions are not met, the task is terminated and the reason for failure is output.

[0036] S104, the ground station splits the version file to be reconstructed into data units of fixed or variable length, assigns a unique number to each data unit, and configures the total number of packets, target write address or target directory and file offset, effective data length, version data and packet verification field, while generating the full file verification value of the source file.

[0037] S105, the ground station transmits data units via the air-to-ground link. The satellite service software caches the data, maintains the receive bitmap, sliding window, or status table using the packet number and total number of packets, removes duplicate packets, and generates selective retransmission requests for packets with check errors, reception timeouts, or missing packets, until a complete satellite service-side reconstructed data is formed; after all packets have been received, the satellite service-side full file checksum is calculated.

[0038] S106, the spacecraft software sends complete data units to the target payload according to the unified payload reconfiguration protocol. The target payload verifies the payload identifier, packet number, target address range, effective length, and packet checksum. After verification, it writes the version data to the target memory address or a temporary version file in the file system. For media such as flash memory, the data can be erased in blocks first and then read back for verification after writing.

[0039] S107 After all data is written, the space service software sends a full file verification request. The target payload rereads the target storage area or temporary version file, calculates the full file verification value using one or more of CRC16, CRC32, SHA-256, hash check, or digital signature check, and sends the result back to the ground station via the space service software.

[0040] S108. When a full file verification fails, the space station software compares its cached data with the full file verification value of the ground source file. If they match, the error may be in the space-to-payload transmission or payload writing stage, and the space station software will resend the corresponding data to the payload. If they do not match, the ground station will resend the corresponding data to the space station software. The target payload can return partial verification results to retransmit only the faulty storage block, file segment, or window.

[0041] S109. After the entire file verification passes, the target payload is set to the version to be enabled flag. The target payload is then reset or switched to the new version in the scheduled task window and a health check is performed. If the health status is not reported within the preset time, the old version or the secure version is restored.

[0042] Figure 3 The illustration shows a satellite payload version reconstruction method according to an embodiment of the present invention, reconstructing data unit fields F01 to F10. The reconstructed data unit includes at least a protocol identifier F01, a target payload identifier F02, a file identifier F03, a packet number F04, a total number of packets F05, target write information F06, effective length F07, version data F08, a packet checksum F09, and a status / extension field F10. For payloads without a file system, F06 is the target memory address; for payloads with a file system, F06 may include the target directory, temporary filename, and file offset.

[0043] Figure 4 This invention illustrates a satellite payload version reconstruction method in one embodiment, including concurrent scheduling of interfaces I01-I03, unified numbering reorganization, and fault degradation. When the target payload has at least two low-speed interfaces, the satellite administration software can allocate data units with different sub-packet numbers to serial port I01, CAN interface I02, network port I03, or other bus interfaces for concurrent transmission. Each interface shares a unified numbering space, acknowledgment window, and deduplication rules. When a certain interface experiences consecutive errors, congestion, or interruption, unacknowledged data units can be migrated to other interfaces, achieving lossless degradation.

[0044] The spacecraft software maintains a unified reconfiguration state machine, which includes at least the following stages: request, capability negotiation, data reception, data retransmission, payload writing, full file verification, version activation, anomaly recovery, and completion. Reconfiguration progress, the current valid version, the version to be activated, and the written length can be stored in non-volatile storage to support resume transmission after power failure, reset, or mission interruption. The status can also be viewed via telemetry downlink.

[0045] The embodiments of this invention also propose further improvements and variations: data units can adopt fixed length, variable length, or adaptive length according to storage erase blocks or file segments; the effective length of the last data unit can be less than the preset packet length. Integrity detection can use a receive bitmap, sliding window, linked list status table, or hierarchical index; selective retransmission requests can carry a set of missing numbers, number range, or bitmap digest. Full file verification can use one or a combination of CRC, hash, or digital signature, and can return partial verification results by storage block, file segment, or acknowledgment window. Payloads without a file system can be written to QSPI FLASH, EEPROM, FRAM, or other non-volatile memory; payloads with a file system can use dual partitions or A / B version areas. Multi-interface scheduling can be dynamically weighted according to interface bandwidth, bit error rate, queue depth, real-time task load, and health status. Reconstruction tasks can be set with a maximum number of retransmissions, a maximum duration, pause conditions, and a manual confirmation point; when the threshold is reached, the task pauses and reports a fault. Version activation methods can be immediate switching, timed switching, switching after payload reset, or triggered by ground commands; automatic rollback is possible when health checks fail. The unified protocol can adapt address layouts, filename rules, verification algorithms, reconstruction windows, and error codes for different payloads through configuration tables without changing the core state machine.

[0046] The beneficial effects of the present invention include at least the following: First, packet loss detection, cache management, selective retransmission, and anomaly recovery are centralized in the relatively resource-rich ground software and space service software, reducing the software size, resource consumption, and verification complexity on the payload side.

[0047] Second, by using a unified message format, a unified state machine, and differentiated parameter configurations to adapt to various loads, we can improve software reusability, interface consistency, and system-level testing efficiency.

[0048] Third, it is compatible with both raw address storage and file system payloads. It can write directly to the target address or write to the directory, file name and file offset, and has good platform versatility.

[0049] Fourth, hierarchical integrity assurance is formed through sub-package verification, satellite-side file verification, and payload-side file verification to improve on-orbit reconfiguration reliability.

[0050] Fifth, by comparing ground source files, satellite cache data, and payload write data, the scope of the fault can be narrowed down and the correct retransmission link can be selected.

[0051] Sixth, selective retransmission, partial retransmission, breakpoint resumption, and persistent reconstruction progress reduce indiscriminate whole file retransmission, shorten recovery time, and reduce link occupancy.

[0052] 7. Multi-interface concurrency can aggregate the bandwidth of multiple low-speed interfaces and migrate and degrade when a single interface fails, thereby improving transmission speed and robustness.

[0053] 8. Temporary area writing, pre-activation verification, old version retention, and rollback upon startup failure reduce the risk of payload failure due to faulty versions.

[0054] 9. Unifying process status, error codes, and telemetry feedback facilitates automated ground operation and maintenance, batch payload management, and reconfiguration process auditing.

[0055] One embodiment of the present invention proposes a unified reconstruction compatible with raw address storage and file systems, including: In step S101, ground station 100 generates a version reconstruction request. The request includes the target payload identifier, the version number to be reconstructed, the file type, the total file length, the whole file verification algorithm, and the preferred interface. After the space service software 200 performs a preliminary verification of the request format and operation permissions, the reconstruction management module 210 sends a capability query message to the target payload 300.

[0056] In step S102, the target payload 300 receives reconstruction capability information from the reconstruction command processing module 310. When using raw memory, the information returned includes the memory base address, available end address, erase granularity, write granularity, address alignment requirements, maximum packet length, and allowed write area. When using a file system, the information returned includes the target directory, remaining space, maximum file size, filename rules, and number of available temporary files.

[0057] Step S103: Ground station 100 performs a feasibility check. If the target payload does not support reconstruction, the version file exceeds the available capacity, the target address is out of bounds, the version type or hardware architecture is incompatible, the version authorization is invalid, or the current reconstruction window is not in effect, the process is terminated and the reason for failure is output; after the verification is passed, the data preparation stage begins.

[0058] Step S104, ground station 100 press Figure 3 The format shown divides the version file into packets. Each data unit contains fields F01 to F10 and generates a packet checksum and a full source file checksum. For raw memory payloads, F06 is obtained by adding the version file start address to the packet offset, and address alignment is performed according to erase and write granularities. For file system payloads, F06 includes the target directory, temporary filename, and file offset. The ground mission file records version metadata, packet status, retransmission count, and checksum.

[0059] In step S105, ground station 100 transmits data units via the air-to-ground link. Buffer module 220 stores the received data; integrity detection module 240 performs format and packet verification, and maintains the receive bitmap based on F04 and F05. If a verification error occurs, a negative acknowledgment is immediately returned; data units not received after the acknowledgment window closes are included in the selective retransmission request. After all packets are received, the satellite service software reassembles them by number and calculates the satellite-side complete file checksum. Only when the checksum matches the ground source file does it proceed to the payload writing stage.

[0060] In step S106, the interface adapter module 230 selects a serial port, CAN, Ethernet port, or other bus according to the target payload capacity, real-time interface load, and interface health status, and sends data units according to a unified protocol. The target payload data verification module 320 verifies the payload identifier, packet number, address range, effective length, and packet verification value. After verification, the storage writing module 330 writes the data. Before writing to flash memory, the data can be erased in erase blocks, and after writing, a readback verification is performed; in file system mode, a temporary version file is written first.

[0061] In step S107, after all data has been written, the satellite software 200 sends a full file verification request. The target payload 300 reads the entire target storage area or temporary version file and calculates the full file verification value using the same algorithm as on the ground. The verification result is fed back to the ground station via telemetry through the satellite software.

[0062] Step S108, as follows Figure 5 As shown, if the payload file verification fails, the space service software first compares the cached data verification value with the ground source file verification value. Figure 5 This embodiment of the invention illustrates the process for locating and hierarchically retransmitting the entire file verification anomaly corresponding to nodes D01 and D02. When the two values ​​match, the anomaly is located in the satellite-to-payload transmission or payload writing stage, and the corresponding data unit is retransmitted. When the two values ​​do not match, the ground station retransmits the abnormal data unit to the satellite. The target payload can return a local verification value calculated by storage block, file segment, or window to achieve local retransmission. When the maximum number of retransmissions is reached, reconstruction is paused and a fault is reported.

[0063] In step S109, after the entire file verification passes, the version status module 340 sets the flag for the version to be enabled and activates the new version through atomic renaming, startup flag switching, or configuration table update. After the new version starts, a health check is performed; if the health status is not reported within a preset time, the startup management program restores the old version or a secure version.

[0064] One embodiment of the present invention proposes multi-interface concurrency and breakpoint resumption, including: such as Figure 4As shown, when the target payload 300 has multiple low-speed interfaces, the interface adaptation module 230 allocates data units with different numbers to channels I01, I02, I03, etc., for concurrent transmission. Odd / even numbering, round-robin, static ratio, or dynamic weighting methods can be used. The target payload is deduplicated, checked, and reassembled according to a unified numbering system; therefore, interface out-of-order transmission will not change the final version content. When an interface experiences consecutive errors, congestion, or interruption, its unacknowledged packets are migrated to healthy interfaces.

[0065] The status management module 250 and the version status module 340 store the task identifier, source file full file checksum, confirmed maximum consecutive packet number, received bitmap digest, written length, temporary file status, and rollback flag in a non-volatile storage area. After link interruption, satellite restart, or payload reset, all parties exchange task identifiers and progress updates, and only transmit data units that are not yet completed or have failed verification, thereby enabling breakpoint resumption.

[0066] One embodiment of the present invention proposes an extended update object, including: the file type in the reconstruction request can indicate a software image, a field-programmable gate array configuration file, an algorithm model, a parameter database, a waveform table, a task script, or a task data packet. The target payload selects the corresponding storage area, verification algorithm, and activation method according to the file type; the core capability negotiation, packet numbering, hierarchical verification, selective retransmission, and anomaly recovery processes remain unchanged.

[0067] This invention has at least the following innovative aspects: First, with capability negotiation and available space feedback as prerequisites, the feasibility of reconstruction, storage boundaries, and version legality verification are completed by the ground side.

[0068] Second, it adopts a unified numbered data unit format, while carrying the target write address or directory and file offset, to achieve unified adaptation of file system-less and file system-enabled payloads.

[0069] Third, cache management, packet loss detection, selective retransmission, and unified state machine are centralized in the satellite service software to reduce the complexity of implementation on the payload side.

[0070] Fourth, establish a three-level verification link for ground source files, satellite cache, and payload written data, and select the correct retransmission direction based on consistency comparison.

[0071] Fifth, it supports partial verification, retransmission of abnormal sections, persistence of received bitmaps and progress, enabling breakpoint resumption and reducing the retransmission of the entire file.

[0072] Sixth, it can concurrently schedule different packets across multiple low-speed interfaces, share a unified numbering space, confirmation window and deduplication rules, and support interface fault migration and lossless degradation.

[0073] 7. Improve on-orbit maintenance security by adopting temporary area writing, full file verification before activation, startup health check, old version retention and failure rollback.

[0074] 8. It manages multiple payloads through a unified message format and differentiated parameter configuration, and can be extended to model, parameter and programmable logic configuration updates beyond software images.

[0075] While some embodiments of the present invention have been described in this application, those skilled in the art will understand that these embodiments are merely illustrative. Numerous variations, alternatives, and improvements will arise in those skilled in the art under the teachings of this invention without departing from its scope. The appended claims are intended to define the scope of the invention and thereby cover methods and structures within the scope of the claims themselves and their equivalents.

Claims

1. A satellite payload version reconstruction method, characterized in that, include: The data units of the payload reconstruction version will be uniformly numbered to ensure consistent adaptation to satellite payloads; as well as Different packets are concurrently scheduled across multiple interfaces based on the unified number to send the reconstructed payload version to the satellite payload.

2. The satellite payload version reconstruction method as described in claim 1, characterized in that, Also includes: With capability negotiation and available space feedback as prerequisites, the ground station provides verification of reconstruction feasibility, storage boundary, and version legality. By using a standardized data unit format with a unified number and carrying the target write address or directory and file offset, it can uniformly adapt to both file system-less and file system-based payloads. as well as The system uses a satellite communication software to manage cache, detect missing packets, perform selective retransmission, and provide a unified state machine.

3. The satellite payload version reconstruction method as described in claim 1, characterized in that, Also includes: A three-level verification link is established, which includes ground source file data verification, satellite cache data verification, and payload write data verification. The retransmission direction is selected based on the consistency comparison of the three-level verification link. Perform partial verification, retransmission of abnormal sections, persistence of received bitmap and progress, and breakpoint resume to replace full file retransmission. A unified numbering space, window confirmation, and deduplication rules are shared among multiple low-speed interfaces. Based on the unified numbering space, window confirmation, and deduplication rules, different sub-packets are concurrently scheduled and interface fault migration and lossless degradation are performed.

4. The satellite payload version reconstruction method as described in claim 1, characterized in that, Also includes: Perform temporary area writing, full file verification before activation, start-up health check, old version retention, and failure rollback to maintain on-orbit safety; The system manages various satellite payloads through a unified message format and differentiated parameter configuration, and provides the unified message format and differentiated parameter configuration to software image external models, software image external parameters, and programmable logic configuration updates.

5. The satellite payload version reconstruction method as described in claim 1, characterized in that, The ground station performs one or more of the following actions: Send a version reconstruction request for the target payload to the satellite software. The version reconstruction request includes the target payload identifier, the version number to be reconstructed, the file type, the total file length, the whole file verification algorithm, and the preferred interface. The feasibility and legality of the reconstruction are verified based on the target payload capacity, available space, size of the file to be reconstructed, version identifier, target hardware model, processor architecture, storage layout, and startup method; if the verification fails, the task is terminated and the reason for failure is output. The payload reconstruction version is split into data units of fixed or variable length, each data unit is assigned a unique number, and the total number of packets, target write address or target directory and file offset, effective data length, version data and packet verification field are configured. At the same time, the full file verification value of the ground source file is generated. as well as The data unit is transmitted via the air-to-ground link; if an anomaly occurs in the air-to-ground link, the corresponding data is retransmitted to the satellite software.

6. The satellite payload version reconstruction method as described in claim 5, characterized in that, The space service software performs one or more of the following actions: Forward the version refactoring request to the target payload; Cache data and maintain a receive bitmap, sliding window or unified status table using packet number and total number of packets. Remove duplicate packets and generate selective retransmission requests for packets with check errors, reception timeouts or missing packets until a complete satellite-side reconstructed data is formed as a complete data unit. After all packets have been received, calculate the full file checksum of the Star Service cache data; The complete data unit is sent to the target payload in accordance with the unified payload reconfiguration protocol; After the target payload has written all the data into the complete data unit, a full file verification request is sent to the target payload. When the entire file verification fails, compare the entire file verification value of the space mission cache data with the entire file verification value of the ground source file; If the two are consistent, the anomaly is determined to be in the space-to-payload transmission or payload writing stage, and the corresponding data is resent to the target payload; If the two are inconsistent, the anomaly is determined to be in the air-to-ground link.

7. The satellite payload version reconstruction method as described in claim 6, characterized in that, The target payload performs one or more of the following actions: Upon receiving a version refactoring request, the system returns refactoring capability information and available storage space information. For payloads without a file system, return the available memory address range, capacity, erase granularity, write granularity, and alignment rules; For loads with file systems, return the remaining space in the target directory, the maximum file size, and the filename rules. The reconstruction capability information also includes interface type, maximum data unit length, supported verification algorithms, and whether it supports breakpoint resume and version rollback; Verify the payload identifier, sub-packet number, target address range, effective length, and sub-packet verification value. Once verified, write the complete data unit of the reconstructed payload version to the target memory address or a temporary version file in the file system. Erase the flash memory in erase blocks and read back to verify after writing; Upon receiving a full file verification request, the target storage area or temporary version file is reread, and the full file verification value of the data is written based on one or more of the following computational payloads: CRC16, CRC32, SHA-256, hash check, or digital signature check. The result is then fed back to the ground station via the space service software. After the entire file verification passes, set the version flag to be enabled, and then reset or switch to the new version and perform a health check in the scheduled task window; If the health status is not reported within the preset time, the old version or a secure version will be restored. If the entire file verification fails and the failure is located in the air-to-ground link, the partial verification result is returned so that only the abnormal storage block, file segment or window is retransmitted.

8. The satellite payload version reconstruction method as described in claim 1, characterized in that, Also includes: The complete data unit includes a protocol identifier, target payload identifier, file identifier, packet number, total number of packets, target write information, effective length, version data, packet checksum, and status / extended field; The file system-less payload includes the target memory address; The file system payload includes the target directory, temporary filename, and file offset; When the target payload has at least two low-speed interfaces, the space service software will allocate data units with different sub-packet numbers to serial ports, CAN interfaces, network ports or other bus interfaces for concurrent transmission. All interfaces share a unified numbering space, confirmation window, and deduplication rules; When a certain interface experiences a series of errors, congestion, or interruption, unacknowledged data units can be migrated to other interfaces for lossless degradation.

9. The satellite payload version reconstruction method as described in claim 1, characterized in that, Also includes: The space service software maintains a unified state machine, including refactoring version requests, capability negotiation, data reception, data retransmission, payload writing, full file verification, version activation, anomaly recovery, and completion status. The reconstruction progress, current valid version, version to be enabled, and length written are saved in non-volatile storage area to support breakpoint resume after power failure, reset, or task interruption. The mission identifier, the complete checksum of the ground source file, the confirmed maximum consecutive packet number, the received bitmap digest, the length written, the temporary file status, and the rollback flag are stored in the non-volatile storage area. After a link interruption, satellite restart, or payload reset, all parties exchange mission identifiers and progress updates, and only transmit data units that are not yet completed or have failed verification to resume transmission from the point of interruption.

10. A satellite payload version reconstruction system, characterized in that, include: The payload version reconstruction ground side is configured to uniformly number the data units of the payload reconstruction version in order to uniformly adapt to the satellite payload; as well as The payload version reconfiguration satellite service software is configured to concurrently schedule different sub-packets across multiple interfaces based on the unified number, so as to send the reconfigured payload version to the satellite payload.

Images