On-orbit reinjection method, device and system for multiple satellite-borne equipment units

Abstract

The invention discloses an on-orbit reinjection method, device and system for multiple satellite-borne equipment units, relates to the technical field of satellite single-machine software and hardware, and mainly aims to solve the problems of high equipment cost and long development period caused by complex design of an existing on-orbit reinjection function. The method mainly comprises the steps that in response to a software reinjection instruction, main control equipment receives software reinjection packages of multiple pieces of equipment to be reinjected transmitted by a ground control center, the main control equipment comprises at least three reinjection package caches, and the equipment to be reinjected comprises main control equipment and single-machine equipment; synchronously storing the software re-injection package into each re-injection package cache; comparing and verifying the cache data of the same software reinjection packet in different reinjection packet caches, and generating a to-be-issued reinjection packet according to the cache data packet passing the comparison and verification; and issuing the to-be-issued re-injection packet to a refreshing chip of the corresponding to-be-re-injected device, so as to perform on-orbit re-injection on a program cache of the to-be-re-injected device through the refreshing chip. The method is mainly used for on-orbit reinjection of a multi-satellite-borne equipment unit.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of satellite single machine software and hardware, and can be applied to the fields of satellites and remote sensing, in particular to an on-orbit re-injection method, device and system for multiple satellite-borne equipment units. BACKGROUND

[0002] With the rapid development of aerospace technology, modern satellite systems gradually evolve towards multi-satellite collaboration and functional integration. A single satellite often carries multiple satellite-borne equipment units, covering different functional modules such as communication, navigation, remote sensing, and scientific experiments, forming a complex heterogeneous system. However, satellite-borne equipment faces multiple challenges during on-orbit operation: the space radiation environment easily causes single-event effects leading to memory data flipping, long-term operation may expose software design flaws, and dynamic changes in mission requirements require software to have rapid iteration capabilities. The traditional ground control center upgrade mode requires satellite return or relies on manual intervention, which is costly and time-consuming, while on-orbit software re-injection technology, which updates program code remotely, has become a core means to ensure reliable operation of satellites throughout their life cycle.

[0003] In the existing technical system and domestic component industry ecological framework, if each satellite-borne single machine device is to have independent software re-injection function and meet high reliability standards, it is in a dilemma of redundant and complex hardware design and serious imbalance in cost structure. From the perspective of hardware design, each satellite-borne single machine device needs to be equipped with independent and complete radiation protection equipment, resulting in high design complexity and equipment cost, and long development cycle. SUMMARY

[0004] Therefore, the present application provides an on-orbit re-injection method, device and system for multiple satellite-borne equipment units, mainly to solve the problem of complex re-injection function design, resulting in high equipment cost and long development cycle.

[0005] According to one aspect of the present application, an on-orbit re-injection method for multiple satellite-borne equipment units is provided, comprising: In response to a software re-injection instruction, a master control device receives software re-injection packages of multiple re-injection devices transmitted by a ground control center, wherein the master control device includes at least three re-injection package caches, and the re-injection devices include the master control device and single machine devices; Synchronously store the software re-injection packages into each re-injection package cache; Compare and verify the cache data of the same software re-injection package in different re-injection package caches, and generate a to-be-downloaded re-injection package according to the cache data that passes the comparison and verification; Downlink the to-be-downloaded re-injection package to the refresh chip of the corresponding re-injection device to perform on-orbit re-injection of the program cache of the re-injection device through the refresh chip.

[0006] Furthermore, the software re-injection package is transmitted at an adaptive link rate, which is determined based on the satellite telemetry and control angle of the target satellite where the master control device is located and the orbital altitude parameters during the transit. The process of determining the adaptive link rate includes: In response to the re-injection packet transmission request, the satellite telemetry and control angle and orbital altitude parameters at the time of the target satellite's transit are obtained, and a re-injection mode activation request is sent to the target update device indicated by the re-injection packet transmission request. Based on the received re-betting mode start request feedback, the initial transmission data packet carried by the re-betting packet transmission request is filtered to obtain the software re-betting packet to be transmitted. The adaptive link rate is calculated based on the size of the software re-injection package, the satellite telemetry and control angle, and the orbital altitude parameters.

[0007] Furthermore, the formula for calculating the adaptive link rate is as follows: ;in, Indicates adaptive link rate. Let represent the size of the re-injection package for the i-th re-injection device, n represent the number of re-injection devices, A represent the satellite tracking angle, R represent the average Earth radius, H represent the average orbital altitude during satellite transit, and G represent the gravitational constant. Indicates the mass of the Earth. This indicates the link transmission efficiency.

[0008] Furthermore, the software re-injection package includes multiple sub-data packets, and the step of synchronously storing the software re-injection package into each of the re-injection package caches includes: For each sub-data packet, the frame header, length, data, and cyclic redundancy check value of the sub-data packet are checked separately. If any verification item fails, the sub-data packet is treated as an abnormal sub-data packet, and a retransmission request for the abnormal sub-data packet is sent to the ground control center. If all verification items pass the verification, the sub-data packet is synchronously stored in each of the re-injection packet caches, wherein the sub-data packets in the same software re-injection packet are stored sequentially in the re-injection packet cache.

[0009] Furthermore, the comparison and verification based on cached data of the same software re-injection package in different re-injection package caches includes: For any software re-injection package, extract the cache data of the software re-injection package from the cache of each re-injection package, wherein the cache data includes the sub-cache data of each sub-data package in the software re-injection package; For each sub-data packet, the sub-cache data taken from different re-betting packet caches are compared. If the sub-cache data in at least two re-betting packet caches are the same, the comparison and verification of the sub-cache data is determined to be successful. If the sub-cache data in each re-betting packet cache are different, the comparison and verification of the sub-cache data is determined to be unsuccessful. If any sub-data packet in the cached data fails the comparison verification, then the comparison verification of the cached data is determined to have failed; if all sub-data packets in the cached data pass the comparison verification, then the comparison verification of the cached data is determined to have passed. The process of generating a re-injection package based on cached data verified by comparison includes: Any cached data that passes the comparison and verification will be used as the re-injection package to be sent.

[0010] Furthermore, after comparing and verifying the cached data of the same software re-injection package in different re-injection package caches, the method further includes: If the cached data in any re-betting package cache fails the verification, update the abnormal frequency of the re-betting package cache; Before the main control device receives the software re-injection packages for multiple devices to be re-injected from the ground control center, the method further includes: In response to a software re-injection command, the abnormal frequency of each re-injection package cache in the master control device is retrieved. If the abnormal frequency is greater than a preset frequency threshold, a master-slave control switch request is generated and sent to the target satellite to switch the execution entity for receiving and sending software re-injection packages from the master control device to the backup control device via the target satellite. The connection relationship between the backup master control device and each individual device and the configuration of the re-injection package cache are the same as those of the master control device. The backup master control device is used to send re-injection packages to be sent to any individual device and the master control device.

[0011] Furthermore, the main control device is equipped with a main control refresh chip and a main control program cache, and the stand-alone device is equipped with a stand-alone refresh chip and a stand-alone program cache, but is not equipped with a re-injection package cache; The step of performing on-orbit re-injection of the program cache of the device to be re-injected through the refresh chip includes: When the device to be re-injected is the main control device or the backup main control device, on-orbit re-injection is performed based on the re-injection package to be issued, through the main control refresh chip and the main control program cache. When the device to be re-injected is a standalone device, on-orbit re-injection is performed based on the re-injection package to be issued, through the standalone refresh chip and the standalone program cache.

[0012] According to another aspect of the present invention, an on-orbit refueling device for a multi-satellite equipment unit is provided, comprising: A transmission module is used to respond to a software re-injection command, wherein the main control device receives software re-injection packets from multiple devices to be re-injected transmitted from the ground control center, wherein the main control device includes at least three re-injection packet buffers, and the devices to be re-injected include the main control device and stand-alone devices; The caching module is used to synchronously store the software re-injection package into each of the re-injection package caches; The verification module is used to compare and verify the cached data of the same software re-injection package in different re-injection package caches, and generate a re-injection package to be distributed based on the cached data that passes the comparison and verification. The re-injection module is used to send the re-injection package to be sent to the refresh chip of the corresponding re-injection device, so as to perform on-orbit re-injection on the program cache of the re-injection device through the refresh chip.

[0013] According to another aspect of the present invention, a system is provided, comprising: a main control device, a backup main control device, and multiple standby devices, wherein the connection relationship between the backup main control device and each standby device and the configuration of the re-injection packet cache are the same as those of the main control device; the main control device is configured with a field-programmable gate array, at least three re-injection packet caches, a main control refresh chip, and a main control program cache; each standby device is configured with a standby refresh chip and a standby program cache, but is not configured with a re-injection packet cache. The field-programmable gate array of the main control device is used to execute the operations corresponding to the on-orbit re-injection method of the above-mentioned multi-satellite equipment unit; The standalone device is used to perform on-orbit re-injection based on the re-injection package to be issued, through the standalone refresh chip and the standalone program cache. The main control device or the backup main control device is also used to perform on-orbit re-injection based on the re-injection package to be issued, through the main control refresh chip and the main control program cache.

[0014] By employing the above-described technical solutions, the technical solutions provided by the embodiments of the present invention have at least the following advantages: This invention provides an on-orbit re-injection method, apparatus, and system for multiple spaceborne equipment units. In this embodiment, in response to a software re-injection command, a master control device receives software re-injection packages from multiple devices to be re-injected, transmitted from a ground control center. The master control device includes at least three re-injection package caches, and the devices to be re-injected include the master control device and individual devices. The software re-injection packages are synchronously stored in each of the re-injection package caches. The cached data of the same software re-injection package in different re-injection package caches are compared and verified, and a re-injection package to be sent is generated based on the cached data that passes the comparison and verification. The re-injection package to be sent is sent to the refresh chip of the corresponding device to be re-injected, so that the program cache of the device to be re-injected can be re-injected in orbit through the refresh chip. The master control device achieves the reception and caching of software re-injection packages for all devices to be re-injected, avoiding the design of re-injection package caches and cache management programs on numerous individual devices, reducing design complexity and equipment costs, while ensuring the data reliability and integrity of the re-injection process.

[0015] The above description is merely an overview of the technical solution of the present invention. In order to better understand the technical means of the present invention, it can be implemented according to the contents of the specification. Furthermore, in order to make the above and other objects, features and advantages of the present invention more apparent and understandable, specific embodiments of the present invention are described below. Attached Figure Description

[0016] Various other advantages and benefits will become apparent to those skilled in the art upon reading the following detailed description of preferred embodiments. The accompanying drawings are for illustrative purposes only and are not intended to limit the invention. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings: Figure 1 A flowchart of an on-orbit re-injection method for a multi-satellite equipment unit provided by an embodiment of the present invention is shown; Figure 2 This diagram illustrates a system hardware architecture block diagram provided by an embodiment of the present invention. Figure 3 This diagram illustrates a block diagram of a main control FPGA software architecture provided by an embodiment of the present invention. Figure 4 This diagram illustrates a block diagram of a single-machine FPGA software architecture provided by an embodiment of the present invention. Figure 5 This diagram illustrates an on-orbit refueling device for a multi-satellite equipment unit according to an embodiment of the present invention. Detailed Implementation

[0017] Exemplary embodiments of the present disclosure will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the disclosure to those skilled in the art.

[0018] To address the issues of complex design, high equipment cost, and long development cycles in existing on-orbit re-injection functions, this invention provides an on-orbit re-injection method for multiple spaceborne equipment units. This method is based on a system implementation comprising a master control device and multiple individual devices. The master control device is equipped with a field-programmable gate array (FPGA), at least three re-injection package caches, a master control refresh chip, and a master control program cache. Each individual device is equipped with a single-device refresh chip and a single-device program cache, but no re-injection package cache. The master control device communicates with each individual device to distribute software re-injection packages for software updates, enabling each individual device to perform software re-injection based on the software re-injection package matching its own device. Furthermore, the master control device can also perform software re-injection on itself. Figure 1 As shown, the method includes: 101. In response to the software re-injection command, the main control device receives software re-injection packages for multiple devices to be re-injected from the ground control center.

[0019] 102. Synchronously store the software re-injection package into each of the re-injection package caches.

[0020] 103. Compare and verify the cached data of the same software re-injection package in different re-injection package caches, and generate the re-injection package to be distributed based on the cached data that passes the comparison and verification.

[0021] 104. The re-injection package to be sent is sent to the refresh chip of the corresponding re-injection device so that the program cache of the re-injection device can be re-injected in orbit through the refresh chip.

[0022] In this embodiment of the invention, the master control device acts as a unified receiving device for software re-injection packages, receiving all software re-injection packages from all devices to be re-injected transmitted from the ground control center. The devices to be re-injected include both individual device units and the master control device itself. Software re-injection instructions can be issued by the ground control center or generated by a preset time trigger; this embodiment of the invention does not impose specific limitations. The master control device is configured with at least three re-injection package caches, each used to store received software re-injection packages. The chip selection for the re-injection package cache is determined based on the degree of influence of high-energy particles in the orbit of the target satellite, in order to minimize the impact of on-orbit high-energy particles on the cache. Based on the differences in the cached data of the software re-injection packages in each re-injection package cache, the cached data is compared and verified. The cached data that passes the comparison and verification is used as the re-injection package to be sent, and sent to the refresh chip of the corresponding device to be re-injected via the interface chip link between the master control device and the devices to be re-injected. The re-injection package to be sent may contain only the cached data of one device to be re-injected, or it may contain the cached data of multiple devices to be re-injected. When the re-injection package to be issued includes cached data from multiple devices to be re-injected, the devices to be re-injected identify the cached data matching themselves from the re-injection package based on the attribute information corresponding to the re-injection package to be issued, such as device ID and software re-injection package code, and then perform on-orbit re-injection of the software based on this cached data.

[0023] It should be noted that by configuring multiple re-injection packet caches, software re-injection packets transmitted from the ground control center are stored synchronously. The software re-injection packets (cache data) stored in different re-injection packet caches are compared to ensure consistency of cache data across multiple caches, achieving a cumulative effect of cache chip performance. This redundant design of the re-injection packet caches enhances the system's fault tolerance and reliability. Even if some cache chips fail, the entire system can continue to operate stably using the remaining healthy chips, ensuring uninterrupted data transmission and storage of software re-injection packets. Simultaneously, the devices to be re-injected in the system are divided into master control devices configured with re-injection packet caches and stand-alone devices without such caches. For scenarios where a satellite carries multiple device units, configuring redundant re-injection packet caches for only one device unit allows for accurate and complete reception of software re-injection packets from all device units, thus achieving global on-orbit software re-injection for all device units. This avoids designing complete software re-injection functions for each device unit individually, significantly reducing the complexity of on-orbit re-injection function design and consequently lowering equipment costs.

[0024] In one embodiment of the present invention, for further explanation and limitation, the software re-injection packet is transmitted according to an adaptive link rate, and the process of determining the adaptive link rate includes: In response to the re-injection packet transmission request, the satellite telemetry and control angle and orbital altitude parameters at the time of transit of the target satellite are obtained, and a re-injection mode activation request is sent to the target update device indicated by the re-injection packet transmission request; the initial transmission data packet carried by the re-injection packet transmission request is filtered according to the feedback of the received re-injection mode activation request to obtain the software re-injection packet to be transmitted; the adaptive link rate is calculated according to the size of the software re-injection packet, the satellite telemetry and control angle and the orbital altitude parameters.

[0025] In this embodiment of the invention, the software re-injection packet is transmitted using an adaptive link rate, which is determined based on the satellite telemetry and control angle of the target satellite where the master control device is located and its orbital altitude parameters during transit. Specifically, when a re-injection packet transmission request is received, the system first obtains the satellite telemetry and control angle and transit orbital altitude parameters of the target satellite, and then sends a re-injection mode start request to the target update device specified in the re-injection packet transmission request. After receiving the re-injection mode start request, the target update device performs internal checks and preparations, and then feeds back the start result to the master control device (re-injection mode start request feedback), which includes whether the start was successful or failed. The start and feedback process for any target update device includes: if a start failure feedback is received for the first time from the target update device, the master control device repeatedly sends the re-injection mode start request to the target update device at a certain preset time interval (e.g., 3 seconds). If the number of repeated requests reaches a preset threshold (e.g., 3 times), the target update device reports a successful start, indicating that the current target update device has completed various preparatory work, such as memory space cleanup and communication interface initialization, and is ready to perform the software re-injection operation. If the number of repeated requests reaches a preset threshold (e.g., 3 times), and the re-injection mode startup request feedback for the target update device still indicates startup failure, it means that the current target update device does not yet meet the conditions for performing software re-injection. This may be due to hardware failure, software conflicts, insufficient resources, or other issues. The target update device will be re-injected during the next batch re-injection. Since the satellite transit window is limited, the target update device that failed to start at this time may not be able to perform on-orbit re-injection before or after the current window. Therefore, during this transmission process, the software re-injection package for the target update device that failed to start re-injection mode may not be transmitted. Only the data packets of the target update devices that successfully started are selected from the initial transmission data packets. That is, if the re-injection mode startup request feedback indicates successful startup, this target update device is identified as the device to be re-injected, and the data packets of the device to be re-injected are identified as the software re-injection packages to be transmitted.

[0026] After the target update device successfully starts and receives the software re-injection package to be transmitted, the adaptive link rate is calculated based on the size of the software re-injection package, the satellite telemetry and control angle, and the orbital altitude parameters. The larger the overall size of each software re-injection package, the longer the transmission time. To ensure transmission within the satellite's transit window, the link rate may need to be increased. Conversely, if the overall size is small, the link rate can be appropriately reduced to ensure the reliability and accuracy of data transmission. When the satellite telemetry and control angle is large, the communication conditions between the ground control center and the satellite are better, and the stability and reliability of signal transmission are higher. In this case, the link rate can be appropriately increased. If the satellite telemetry and control angle is small, the communication conditions are relatively poor, and the link rate needs to be reduced to ensure the accuracy of data transmission. The higher the orbital altitude, the farther the signal travels in space, and the greater the attenuation. To ensure the signal accurately reaches the target satellite, the link rate needs to be reduced. Conversely, when the orbital altitude is low, the link rate can be appropriately increased. Therefore, by calculating the link rate used for software re-injection packet transmission based on the size of the software re-injection packet, the satellite telemetry and control angle, and the orbital altitude parameters, the link rate can be adapted to the real-time environment, ensuring the integrity and reliability of data transmission.

[0027] Specifically, the formula for calculating the adaptive link rate can be expressed as: ; in, Indicates adaptive link rate. Let represent the size of the re-injection package for the i-th re-injection device, n represent the number of re-injection devices, A represent the satellite tracking angle, R represent the average Earth radius, H represent the average orbital altitude during satellite transit, and G represent the gravitational constant. Indicates the mass of the Earth. The link transmission efficiency can be determined based on historical data of the target satellite.

[0028] In one embodiment of the present invention, for further explanation and limitation, the step of synchronously storing the software re-injection package into each of the re-injection package caches includes: For each sub-data packet, the frame header, length, data, and cyclic redundancy check value of the sub-data packet are checked separately. If any verification item fails, the sub-data packet is treated as an abnormal sub-data packet, and a retransmission request for the abnormal sub-data packet is sent to the ground control center. If all verification items pass the verification, the sub-data packet is synchronously stored in each of the re-injection packet caches.

[0029] In this embodiment of the invention, the software re-injection packet includes multiple sub-data packets, that is, the software re-injection packet of a device to be re-injected is divided into multiple sub-data packets. During the process of synchronously storing the software re-injection packet into each re-injection packet cache, the frame header, length, data, and cyclic redundancy check (CRC) value of each sub-data packet are rigorously verified. Specifically, the frame header contains key identification information of the sub-data packet, such as packet type and sequence number. Verifying the frame header ensures the correct identity of the sub-data packet, avoiding the reception of packets of incorrect types or packets with disordered sequences. Verifying the length of the sub-data packet can determine whether data loss or extra data insertion has occurred during transmission, ensuring the data integrity of the sub-data packet. Directly checking the actual data carried by the sub-data packet is a crucial step in ensuring the accuracy of core content such as software function code. CRC is calculated by comparing the CRC value of the received sub-data packet with a pre-calculated value, which can quickly detect whether bit errors have occurred during data transmission.

[0030] For each sub-data packet, if one, two, or more of the above checks fail, this sub-data packet is considered an abnormal sub-data packet, and a retransmission request is sent to the ground control center, requesting the ground control center to retransmit the abnormal sub-data packet to ensure the integrity and accuracy of the software re-injection packet. If all checks pass, the sub-data packet is synchronously stored in each of the aforementioned re-injection packet caches, and stored in the order in which each sub-data packet was segmented in the software re-injection packet, thus obtaining the re-injection packet cache corresponding to this software re-injection packet. That is, the sub-data packets in the same software re-injection packet are stored sequentially in the re-injection packet cache.

[0031] It should be noted that during the transmission of software re-injection packets between satellites and ground stations, the complex satellite orbit and long signal transmission distance make the communication link highly susceptible to interference from cosmic rays and atmospheric disturbances, leading to errors in data transmission. By dividing the complete software re-injection packet into multiple smaller packets—for example, dividing a 100MB packet into 100 1MB sub-packets—in subsequent transmissions, even if some sub-packets still malfunction due to interference, only those erroneous sub-packets need to be retransmitted. For instance, if five sub-packets malfunction in a single transmission, only 5MB of data needs to be retransmitted, significantly reducing the retransmission volume by 95% compared to retransmitting the entire 100MB packet. This method significantly improves satellite communication efficiency and reduces resource waste.

[0032] In one embodiment of the present invention, for further explanation and limitation, the comparison and verification based on cached data of the same software re-injection package in different re-injection package caches includes: For any software re-injection package, extract the cache data of the software re-injection package from the cache of each re-injection package, wherein the cache data includes the sub-cache data of each sub-data package in the software re-injection package; For each sub-data packet, the sub-cache data taken from different re-betting packet caches are compared. If the sub-cache data in at least two re-betting packet caches are the same, the comparison and verification of the sub-cache data is determined to be successful. If the sub-cache data in each re-betting packet cache are different, the comparison and verification of the sub-cache data is determined to be unsuccessful. If any sub-data packet in the cached data fails the comparison verification, then the comparison verification of the cached data is determined to have failed; if all sub-data packets in the cached data pass the comparison verification, then the comparison verification of the cached data is determined to have passed. The process of generating a re-injection package based on cached data verified by comparison includes: Any cached data that passes the comparison and verification will be used as the re-injection package to be sent.

[0033] In this embodiment of the invention, for any software re-injection package, cache data corresponding to the software re-injection package is extracted from each re-injection package cache. This cache data covers the sub-cache data of each sub-data packet in the software re-injection package. Then, for each sub-data packet, the sub-cache data retrieved from different re-injection package caches is compared one by one. If at least two re-injection package caches show identical sub-cache data, the comparison verification of that sub-cache data is considered successful; otherwise, if all the sub-cache data in each re-injection package cache are different, the comparison verification of that sub-cache data is considered unsuccessful. Then, all sub-data packets in the cache data are comprehensively evaluated. If the comparison verification of any one sub-data packet in the cache data fails, the comparison verification of the entire cache data is considered unsuccessful; only when the comparison verification of all sub-data packets in the cache data passes is the comparison verification of that cache data considered successful. After completing the comparison verification of the cache data, the process enters the re-injection package generation stage, where any cache data that passes the comparison verification is directly used as the re-injection package to be sent. Sub-data packets that fail the comparison and verification of sub-cached data will also be treated as abnormal sub-data packets, and a retransmission request for the abnormal sub-data packets will be sent to the ground control center. The cache and comparison and verification will be carried out again based on the retransmitted sub-data packets until the comparison and verification of all sub-data packets in the cached data pass. Then, the cached data will be used as a re-injection packet to be sent.

[0034] In one embodiment of the present invention, for further explanation and limitation, after comparing and verifying the cached data of the same software re-injection package in different re-injection package caches, the method further includes: If the cached data in any re-betting package cache fails the verification, update the abnormal frequency of the re-betting package cache; Before the main control device receives the software re-injection packages for multiple devices to be re-injected from the ground control center, the method further includes: In response to the software re-injection command, the abnormal frequency of each re-injection package cache in the master control device is retrieved. If the abnormal frequency is greater than a preset frequency threshold, a master-slave control switch request is generated and sent to the target satellite to switch the execution entity for receiving and sending the software re-injection package from the master control device to the backup control device via the target satellite.

[0035] In this embodiment of the invention, the system is also equipped with a backup master control device. The connection relationship between the backup master control device and each individual device, as well as the configuration of the re-injection packet cache in the device, are the same as those of the master control device. The master control device and the backup master control device can achieve cross-control of multiple individual devices, enhancing the reliability and flexibility of the system. As a redundant design of the master control device, the backup master control device performs the same function as the master control device, namely, it sends re-injection packets to be sent to any individual device and the master control device, so as to switch to the backup master control device in a timely manner when the master control device fails, thereby improving the reliability of on-orbit re-injection.

[0036] The interference factors in the space environment are complex. Storage anomalies in the re-injection packet cache may be caused by transient interference or by a malfunction in the cache chip. To identify cache chip anomalies and repair them promptly, the frequency of anomalies in the re-injection packet cache that result in verification failure is dynamically updated after a verification failure, reflecting the frequency of problems over a period of time. Upon receiving a response to a software re-injection command, the latest anomaly frequency of the current master control device is retrieved first and compared with a preset frequency threshold. When the anomaly frequency exceeds the preset threshold, it indicates that the current master control device's re-injection packet cache is frequently experiencing problems, potentially causing risks or malfunctions in the master control device's processing of software re-injection packets. At this point, a master-slave control switchover request is generated and sent to the target satellite to activate the backup master control device. This switches the execution entity for receiving and sending software re-injection packets from the current master control device to the backup master control device, allowing the backup master control device to respond to software re-injection commands and execute the reception and sending of software re-injection packets, ensuring stable and reliable reception and sending of software re-injection packets. The preset frequency threshold can be customized according to actual needs, and this embodiment of the invention does not impose specific limitations. Of course, the triggering of the execution subject switching mechanism is not limited to the abnormal frequency of the re-injection package cache, but can also include the triggering of other abnormal situations, and this embodiment of the invention does not impose specific limitations. It should be noted that the primary control device and the backup primary control device are mutually supportive, and the number of backup primary control devices is not limited to one. The primary control device and the backup primary control device do not refer to a specific device, but rather the device currently in operation is designated as the primary control device, and the device currently in non-operational state is designated as the backup primary control device.

[0037] In one embodiment of the present invention, for further explanation and limitation, the stand-alone device is equipped with a stand-alone refresh chip and a stand-alone program cache, but is not equipped with a re-injection package cache; The step of performing on-orbit re-injection of the program cache of the device to be re-injected through the refresh chip includes: When the device to be re-injected is the main control device or the backup main control device, on-orbit re-injection is performed based on the re-injection package to be issued, through the main control refresh chip and the main control program cache. When the device to be re-injected is a standalone device, on-orbit re-injection is performed based on the re-injection package to be issued, through the standalone refresh chip and the standalone program cache.

[0038] In this embodiment of the invention, the main control device is also equipped with a main control refresh chip and a main control program cache. During the software-based on-orbit re-injection operation, the main control device exhibits strong flexibility, possessing bidirectional re-injection capabilities. When the device to be re-injected is a standalone device (camera), the main control device initiates a re-injection process to the standalone device based on the determined re-injection package to be sent. At this time, the main control device sends the data of the re-injection package to the standalone device, and the standalone device, with the help of its standalone refresh chip and standalone program cache, completes its own program update and re-injection according to the received data, thereby adjusting motor operating parameters or control logic, etc. When it is necessary to update the program of the main control device itself, it also performs on-orbit re-injection work based on the re-injection package to be sent, using its own main control refresh chip and main control program cache.

[0039] It should be noted that the main control device can re-inject both individual devices (cameras) and itself, ensuring that the programs of all critical devices in the system are updated in a timely manner. Whether it is a single device needing to adjust control parameters due to changes in the operating environment, or the main control device needing to update its program for function upgrades or vulnerability fixes, this can all be achieved through the main control device's re-injection operation, thereby improving the functional integrity and adaptability of the entire system.

[0040] In one application example, the primary and backup primary controllers are the main control systems for a satellite or payload, used to control the operation of all individual units on the satellite or payload. The backup primary controller is a backup device for the primary controller. In practical applications, depending on specific needs, the primary and backup devices can be used simultaneously, or only the primary controller can be used, thus achieving a balance between system reliability and cost. The primary and backup primary controllers have identical functions and interfaces, allowing for mass production. Figure 2 As shown, the main controller (primary) or main controller (backup) is mainly used for the reception, verification, caching, and control of the re-injection data packet and the re-injection process. Both the main controller (primary) and the main controller (backup) include a Field Programmable Gate Array (FPGA), interface chip 1, cache FLASH1, cache FLASH2, cache FLASH3, interface chip 2, refresh chip, FLASH1_M (FLASH1_B corresponding to the main controller (backup)), and FLASH2_M (FLASH2_B corresponding to the main controller (backup)).

[0041] Interface chip 1 can be an RS422 interface, CAN interface, optical fiber interface, RS485 interface, RS232 interface, or general network interface, etc., used for communication between the satellite and the main control FPGA and for receiving software re-injection packets. The refresh chip is used to refresh the FPGA in orbit, improving reliability. The FPGA software is stored in FLASH1_M and FLASH2_M (or FLASH1_B and FLASH2_B), and the two caches can back each other up or have different functions. During FPGA software re-injection, the refresh chip controls the reading and writing of FLASH1_M or FLASH2_M (or FLASH1_B and FLASH2_B).

[0042] FLASH1, FLASH2, and FLASH3 are used to decode the software re-injection packets sent from the ground to the FPGA via satellite and store them in the cache FLASH. After all re-injection packets have been received, they are read from the cache FLASH, converted by the FPGA protocol, and sent to the refresh chip. Interface chip 2 is used for communication between the main controller (primary) or main controller (backup) and individual devices 1 to n, and to control the software re-injection of individual devices. Interface chip 2 can be an RS422 interface, CAN interface, optical fiber interface, RS485 interface, RS232 interface, general network interface, etc. Each individual device is a device unit of the satellite or a single unit of the payload, mainly used to implement a certain design function of the satellite or payload.

[0043] The refresh chip in the standalone device is used to refresh the FPGA on-orbit, improving reliability. The FPGA software is stored in the corresponding FLASH memory; the two caches can be mutually backed up or have different functions. During FPGA software remapping, the refresh chip controls the read and write operations of the two caches.

[0044] In one application example, the system's software architecture includes a main control FPGA software architecture and a standalone FPGA software architecture. For example... Figure 3 As shown, the main control FPGA software architecture includes a satellite interface module, a satellite command interpretation module, a downlink telemetry packetization module, a task management module, a cache control module, a comparison and correction module, a command encoding module, a telemetry interpretation module, and stand-alone interface modules 1 to n.

[0045] The system comprises the following modules: Satellite Interface Module: Drivers for the underlying interface chip, encoding and decoding the underlying physical layer protocol, and buffering. Satellite Command Decoding Module: Decodes commands received from the satellite interface according to the satellite's agreed-upon protocol, interpreting them into control fields or time sequences required for master control execution, and buffering them. Telemetry Packaging Module: Encodes and packages data according to the satellite's agreed-upon protocol at the protocol layer and transmits it to the satellite interface for downlink. Buffer Control Module: Controls read / write operations, sector control, and bad block detection for the three buffer FLASH memory locations. Comparison and Correction Module: Compares data read from the three buffer FLASH memory locations, selecting three identical or two identical data points as the correct output. Command Encoding Module: Controls the stand-alone unit to execute specified actions, encoding corresponding commands into an agreed-upon command format and transmitting them to the stand-alone interface module. Telemetry Decoding Module: Decodes the stand-alone telemetry status received by the stand-alone interface module into the status that the master control needs to monitor, buffers it, performs telemetry status transcoding according to ground requirements, and transmits it to the telemetry packaging module. Stand-alone Interface Module: Handles physical layer protocol conversion and data transmission between the master control and stand-alone units.

[0046] This invention provides an on-orbit re-injection method for multiple spaceborne equipment units. In this embodiment, in response to a software re-injection command, a master control device receives software re-injection packages from multiple devices to be re-injected, transmitted from a ground control center. The master control device includes at least three re-injection package caches, and the devices to be re-injected include the master control device and individual devices. The software re-injection packages are synchronously stored in each of the re-injection package caches. The cached data of the same software re-injection package in different re-injection package caches are compared and verified, and a re-injection package to be sent is generated based on the cached data that passes the comparison and verification. The re-injection package to be sent is sent to the refresh chip of the corresponding device to be re-injected, so that the refresh chip performs on-orbit re-injection of the program cache of the device to be re-injected. The master control device achieves the reception and caching of software re-injection packages for all devices to be re-injected, avoiding the design of re-injection package caches and cache management programs on numerous individual devices, reducing design complexity and equipment costs, while ensuring the data reliability and integrity of the re-injection process.

[0047] like Figure 4 As shown, the standalone FPGA software architecture includes a standalone interface module, an instruction decoding module, a telemetry encoding module, a refresh chip interaction module, and a standalone task management module.

[0048] The standalone interface module receives commands or re-injection data packets from the master controller at the physical layer, or sends the telemetry status of the telemetry encoding module to the master controller. The command interpretation module interprets the commands sent from the master controller to the standalone unit into executable commands and caches them. The standalone task management module manages standalone tasks, executes commands, collects standalone status data, and handles data packet interaction during re-injection. The refresh chip interaction module interprets data packets during software updates into refresh chip protocols.

[0049] Furthermore, as a response to the above Figure 1 The implementation of the method shown in this invention provides an on-orbit refueling device for multiple spaceborne equipment units, such as... Figure 5 As shown, the device includes: Transmission module 31 is used to respond to software re-injection instructions, wherein the main control device receives software re-injection packets from multiple devices to be re-injected transmitted from the ground control center, wherein the main control device includes at least three re-injection packet caches, and the devices to be re-injected include the main control device and stand-alone devices; Cache module 32 is used to synchronously store the software re-injection package into each of the re-injection package caches; The verification module 33 is used to compare and verify the cached data of the same software re-injection package in different re-injection package caches, and generate a re-injection package to be sent based on the cached data that passes the comparison and verification. The re-injection module 34 is used to send the re-injection package to be sent to the refresh chip of the corresponding re-injection device, so as to perform on-orbit re-injection on the program cache of the re-injection device through the refresh chip.

[0050] This invention provides an on-orbit re-injection device for multiple spaceborne equipment units. In this embodiment, in response to a software re-injection command, a master control device receives software re-injection packages from multiple devices to be re-injected, transmitted from a ground control center. The master control device includes at least three re-injection package caches, and the devices to be re-injected include the master control device and individual devices. The software re-injection packages are synchronously stored in each of the re-injection package caches. The cached data of the same software re-injection package in different re-injection package caches are compared and verified, and a re-injection package to be sent is generated based on the cached data that passes the comparison and verification. The re-injection package to be sent is sent to the refresh chip of the corresponding device to be re-injected, so that the refresh chip performs on-orbit re-injection of the program cache of the device to be re-injected. The master control device achieves the reception and caching of software re-injection packages for all devices to be re-injected, avoiding the design of re-injection package caches and cache management programs on numerous individual devices, reducing design complexity and equipment cost, while ensuring the data reliability and integrity of the re-injection process.

[0051] Furthermore, the device also includes: The acquisition module is used to respond to the re-injection packet transmission request, acquire the satellite telemetry and control angle and orbital altitude parameters of the target satellite during its transit, and send a re-injection mode activation request to the target update device indicated by the re-injection packet transmission request. The filtering module is used to filter the initial transmission data packet carried by the re-injection packet transmission request based on the received re-injection mode start request feedback, so as to obtain the software re-injection packet to be transmitted. The calculation module is used to calculate the adaptive link rate based on the size of the software re-injection package, the satellite telemetry and control angle, and the orbital altitude parameters.

[0052] Furthermore, in specific application scenarios, the calculation module is specifically used to calculate the adaptive link rate based on the formula for calculating the adaptive link rate, wherein the formula for calculating the adaptive link rate is: ;in, Indicates adaptive link rate. Let represent the size of the re-injection package for the i-th re-injection device, n represent the number of re-injection devices, A represent the satellite tracking angle, R represent the average Earth radius, H represent the average orbital altitude during satellite transit, and G represent the gravitational constant. Indicates the mass of the Earth. This indicates the link transmission efficiency.

[0053] Furthermore, the cache module 32 includes: The verification unit is used to verify the frame header, length, data, and cyclic redundancy check value of each sub-data packet. The determining unit is used to identify the sub-data packet as an abnormal sub-data packet and send a retransmission request for the abnormal sub-data packet to the ground control center if the verification of any verification item fails. A storage unit is used to synchronously store the sub-data packet into each of the re-injection package caches if all verification items pass the verification. In the re-injection package cache, each sub-data packet in the same software re-injection package is stored sequentially.

[0054] Furthermore, the verification module 33 includes: The extraction unit is used to extract cache data of the software re-injection package from the cache of each re-injection package for any software re-injection package, wherein the cache data includes sub-cache data of each sub-data package in the software re-injection package; The comparison unit is used to compare the sub-cache data taken from different re-injection packet caches for each sub-data packet. If the sub-cache data in at least two re-injection packet caches are the same, it is determined that the comparison verification of the sub-cache data has passed. If the sub-cache data in each re-injection packet cache are different, it is determined that the comparison verification of the sub-cache data has failed. The first determining unit is configured to determine that the comparison verification of the cached data has failed if any sub-data packet in the cached data fails the comparison verification, and to determine that the comparison verification of the cached data has passed if all sub-data packets in the cached data pass the comparison verification. The second determining unit is used to take any cached data that passes the comparison and verification as the re-injection package to be sent.

[0055] Furthermore, the device also includes: The master / slave switching module is used to update the abnormal frequency of the re-betting package cache if the cache data verification in any re-betting package cache fails. Before the main control device receives the software re-injection packages for multiple devices to be re-injected from the ground control center, the method further includes: In response to a software re-injection command, the abnormal frequency of each re-injection package cache in the master control device is retrieved. If the abnormal frequency is greater than a preset frequency threshold, a master-slave control switch request is generated and sent to the target satellite to switch the execution entity for receiving and sending software re-injection packages from the master control device to the backup control device via the target satellite. The connection relationship between the backup master control device and each individual device and the configuration of the re-injection package cache are the same as those of the master control device. The backup master control device is used to send re-injection packages to be sent to any individual device and the master control device.

[0056] Furthermore, the re-injection module includes: The master control re-injection unit is used to perform on-orbit re-injection based on the re-injection package to be sent, in the case where the device to be re-injected is the master control device or the backup master control device, through the master control refresh chip and the master control program cache. The single-machine re-injection unit is used to perform on-orbit re-injection based on the re-injection package to be issued, using the single-machine refresh chip and the single-machine program cache, when the device to be re-injected is a single-machine device.

[0057] According to an embodiment of the present invention, a system may include: a master control device, a backup master control device, and multiple standby devices, wherein the connection relationship between the backup master control device and each standby device and the configuration of the re-betting packet cache are the same as those of the master control device. The master control device is configured with a field-programmable gate array, at least three re-betting packet caches, a master control refresh chip, and a master control program cache. Each standby device is configured with a standby refresh chip and a standby program cache, but is not configured with a re-betting packet cache. The field-programmable gate array of the main control device is used to execute the operations corresponding to the on-orbit re-injection method of the above-mentioned multi-satellite equipment unit; The standalone device is used to perform on-orbit re-injection based on the re-injection package to be issued, through the standalone refresh chip and the standalone program cache. The main control device or the backup main control device is also used to perform on-orbit re-injection based on the re-injection package to be issued, through the main control refresh chip and the main control program cache.

[0058] It is obvious to those skilled in the art that the modules or steps of the present invention described above can be implemented using general-purpose computing devices. They can be centralized on a single computing device or distributed across a network of multiple computing devices. Optionally, they can be implemented using computer-executable program code, thereby storing them in a storage device for execution by a computing device. In some cases, the steps shown or described can be performed in a different order than those presented herein, or they can be fabricated as separate integrated circuit modules, or multiple modules or steps can be fabricated as a single integrated circuit module. Thus, the present invention is not limited to any particular combination of hardware and software.

[0059] The above description is merely a preferred embodiment of the present invention and is not intended to limit the invention. Various modifications and variations can be made to the present invention by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A method for on-orbit refueling of a multi-satellite equipment unit, characterized in that, include: In response to a software re-injection command, the master control device receives multiple software re-injection packets from multiple devices to be re-injected transmitted from the ground control center. The master control device includes at least three re-injection packet caches, and the devices to be re-injected include the master control device and stand-alone devices. The software re-injection package is synchronously stored in each of the re-injection package caches; The cached data of the same software re-injection package in different re-injection package caches are compared and verified, and a re-injection package to be distributed is generated based on the cached data that passes the comparison and verification. The re-injection package to be sent is sent to the refresh chip of the corresponding re-injection device so that the program cache of the re-injection device can be re-injected in orbit through the refresh chip.

2. The on-orbit refueling method for multi-satellite equipment units according to claim 1, characterized in that, The software re-injection package is transmitted at an adaptive link rate, which is determined based on the satellite telemetry and control angle and orbital altitude parameters of the target satellite where the main control device is located during its transit. The process of determining the adaptive link rate includes: In response to the re-injection packet transmission request, the satellite telemetry and control angle and orbital altitude parameters at the time of the target satellite's transit are obtained, and a re-injection mode activation request is sent to the target update device indicated by the re-injection packet transmission request. Based on the received re-betting mode start request feedback, the initial transmission data packet carried by the re-betting packet transmission request is filtered to obtain the software re-betting packet to be transmitted. The adaptive link rate is calculated based on the size of the software re-injection package, the satellite telemetry and control angle, and the orbital altitude parameters.

3. The on-orbit refueling method for multi-satellite equipment units according to claim 2, characterized in that, The formula for calculating the adaptive link rate is as follows: ;in, Indicates adaptive link rate. Let represent the size of the re-injection package for the i-th re-injection device, n represent the number of re-injection devices, A represent the satellite tracking angle, R represent the average Earth radius, H represent the average orbital altitude during satellite transit, and G represent the gravitational constant. Indicates the mass of the Earth. This indicates the link transmission efficiency.

4. The on-orbit refueling method for multi-satellite equipment units according to claim 1, characterized in that, The software re-injection package includes multiple sub-data packets, and the step of synchronously storing the software re-injection package into each of the re-injection package caches includes: For each sub-data packet, the frame header, length, data, and cyclic redundancy check value of the sub-data packet are checked separately. If any verification item fails, the sub-data packet is treated as an abnormal sub-data packet, and a retransmission request for the abnormal sub-data packet is sent to the ground control center. If all verification items pass the verification, the sub-data packet is synchronously stored in each of the re-injection packet caches, wherein the sub-data packets in the same software re-injection packet are stored sequentially in the re-injection packet cache.

5. The on-orbit refueling method for multi-satellite equipment units according to claim 4, characterized in that, The comparison and verification based on cached data of the same software re-injection package in different re-injection package caches includes: For any software re-injection package, extract the cache data of the software re-injection package from the cache of each re-injection package, wherein the cache data includes the sub-cache data of each sub-data package in the software re-injection package; For each sub-data packet, the sub-cache data taken from different re-betting packet caches are compared. If the sub-cache data in at least two re-betting packet caches are the same, the comparison and verification of the sub-cache data is determined to be successful. If the sub-cache data in each re-betting packet cache are different, the comparison and verification of the sub-cache data is determined to be unsuccessful. If any sub-data packet in the cached data fails the comparison verification, then the comparison verification of the cached data is determined to have failed; if all sub-data packets in the cached data pass the comparison verification, then the comparison verification of the cached data is determined to have passed. The process of generating a re-injection package based on cached data verified by comparison includes: Any cached data that passes the comparison and verification will be used as the re-injection package to be sent.

6. The on-orbit refueling method for multi-satellite equipment units according to claim 1, characterized in that, After comparing and verifying the cached data of the same software re-injection package in different re-injection package caches, the method further includes: If the cached data in any re-betting package cache fails the verification, update the abnormal frequency of the re-betting package cache; Before the main control device receives the software re-injection packages for multiple devices to be re-injected from the ground control center, the method further includes: In response to a software re-injection command, the abnormal frequency of each re-injection package cache in the master control device is retrieved. If the abnormal frequency is greater than a preset frequency threshold, a master-slave control switch request is generated and sent to the target satellite to switch the execution entity for receiving and sending software re-injection packages from the master control device to the backup master control device via the target satellite. The connection relationship between the backup master control device and each individual device and the configuration of the re-injection package cache are the same as those of the master control device. The backup master control device is used to send re-injection packages to be sent to any individual device and the master control device.

7. The on-orbit refueling method for multi-satellite equipment units according to claim 6, characterized in that, The main control device is equipped with a main control refresh chip and a main control program cache, and the stand-alone device is equipped with a stand-alone refresh chip and a stand-alone program cache, but is not equipped with a re-injection package cache. The step of performing on-orbit re-injection of the program cache of the device to be re-injected through the refresh chip includes: When the device to be re-injected is the main control device or the backup main control device, on-orbit re-injection is performed based on the re-injection package to be issued, through the main control refresh chip and the main control program cache. When the device to be re-injected is a standalone device, on-orbit re-injection is performed based on the re-injection package to be issued, through the standalone refresh chip and the standalone program cache.

8. An on-orbit refueling device for a multi-spaceborne equipment unit, characterized in that, include: A transmission module is used to respond to a software re-injection command. The main control device receives software re-injection packets from multiple devices to be re-injected from the ground control center. The main control device includes at least three re-injection packet buffers, and the devices to be re-injected include the main control device and stand-alone devices. The caching module is used to synchronously store the software re-injection package into each of the re-injection package caches; The verification module is used to compare and verify the cached data of the same software re-injection package in different re-injection package caches, and generate a re-injection package to be distributed based on the cached data that passes the comparison and verification. The re-injection module is used to send the re-injection package to be sent to the refresh chip of the corresponding re-injection device, so as to perform on-orbit re-injection on the program cache of the re-injection device through the refresh chip.

9. A system, characterized in that, include: The system comprises a master control device, a backup master control device, and multiple standby devices. The connection relationship between the backup master control device and each standby device, as well as the configuration of the re-injection packet cache, are the same as those of the master control device. The master control device is configured with a field-programmable gate array, at least three re-injection packet caches, a master control refresh chip, and a master control program cache. Each standby device is configured with a standby refresh chip and a standby program cache, but is not configured with a re-injection packet cache. The field-programmable gate array of the main control device is used to perform the operation corresponding to the on-orbit re-injection method of the multi-satellite equipment unit as described in any one of claims 1-6; The stand-alone device is used to perform on-orbit re-injection based on the re-injection package to be issued, through the stand-alone refresh chip and the stand-alone program cache. The main control device or the backup main control device is also used to perform on-orbit re-injection based on the re-injection package to be issued, through the main control refresh chip and the main control program cache.

Images