On-orbit re-annotation method, device and system for multi-satellite device unit

Abstract

The application discloses a kind of on-orbit reprogramming methods and devices of multiple satellite-borne equipment units, system, it is related to satellite single machine software and hardware technical field, main purpose is to solve the problem of existing on-orbit reprogramming function design complex, leading to equipment cost high and long development cycle.The main include in response to software reprogramming instruction, main control equipment receives the software reprogramming package of multiple reprogramming equipment transmitted by ground control center, wherein the main control equipment includes at least three reprogramming package cache, reprogramming equipment includes main control equipment and single machine equipment;Software reprogramming package is stored in each reprogramming package cache synchronously;The cache data of the same software reprogramming package in different reprogramming package cache is compared and checked, and generates reprogramming package to be issued according to the cache data package that passes through comparison and checking;Reprogramming package to be issued is issued to the refresh chip of corresponding reprogramming equipment, to carry out on-orbit reprogramming to the program cache of reprogramming equipment by refresh chip.It is mainly used for on-orbit reprogramming of multiple satellite-borne equipment units.

Description

Technical Field

[0001] This invention relates to the field of satellite single-unit hardware and software technology, and can be applied to the fields of satellites and remote sensing. In particular, it relates to an on-orbit re-injection method, device, and system for multiple satellite-borne equipment units. Background Technology

[0002] With the rapid development of aerospace technology, modern satellite systems are gradually evolving towards multi-satellite collaboration and functional integration. A single satellite often carries multiple onboard equipment units, covering different functional modules such as communication, navigation, remote sensing, and scientific experiments, forming a complex heterogeneous system. However, onboard equipment faces multiple challenges during on-orbit operation: the space radiation environment can easily trigger single-event effects, causing data flipping in memory; long-term operation may expose software design flaws; and dynamic changes in mission requirements demand that software possess rapid iteration capabilities. Traditional ground control center upgrade methods require satellite return or rely on manual intervention, which is costly and lacks timeliness. On-orbit reprogramming technology, through remotely updating program code, has become a core means of ensuring reliable operation throughout the satellite's entire lifecycle.

[0003] Within the existing technological system and domestic component industry ecosystem, achieving the goal of ensuring each spaceborne unit has independent software refactoring capabilities and meets high reliability standards is currently fraught with challenges, including redundant and complex hardware design and a severely unbalanced cost structure. From a hardware design perspective, each spaceborne unit needs to be equipped with independent, complete sets of radiation protection equipment, resulting in high design complexity, high equipment costs, and long development cycles. Summary of the Invention

[0004] In view of this, the present invention provides an on-orbit refueling method, apparatus, and system for multiple spaceborne equipment units, the main purpose of which is to solve the problems of complex design of existing on-orbit refueling functions, resulting in high equipment costs and long development cycles.

[0005] According to one aspect of the present invention, an on-orbit re-injection method for multiple spaceborne equipment units is provided, comprising:

[0006] 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.

[0007] The software re-injection package is synchronously stored in each of the re-injection package caches;

[0008] 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.

[0009] The software re-injection package is transmitted to a refresh chip of a corresponding re-injection device to be re-injected, so as to re-inject the program cache of the re-injection device to be re-injected by the refresh chip.

[0010] Further, the software re-injection package is transmitted according to an adaptive link rate determined according to a satellite control angle of a target satellite where the master device is located and an orbit height parameter at a transit time.

[0011] The determination process of the adaptive link rate comprises:

[0012] In response to a re-injection package transmission request, the satellite control angle of the target satellite and the orbit height parameter at the transit time are acquired, and a re-injection mode start request is sent to a target update device indicated by the re-injection package transmission request.

[0013] According to the received re-injection mode start request, the initial transmission data package carried by the re-injection package transmission request is filtered to obtain a software re-injection package to be transmitted.

[0014] The adaptive link rate is calculated according to the size of the software re-injection package, the satellite control angle and the orbit height parameter.

[0015] Further, the calculation formula of the adaptive link rate is ; wherein, the adaptive link rate is represented by A, the size of the re-injection software package of the i-th re-injection device, n represents the number of re-injection devices, A represents the satellite control angle, R represents the average earth radius, H represents the average orbit height of the satellite at the transit time, G represents the gravitational constant, the earth mass is represented by M, and the link transmission efficiency is represented by G.

[0016] Further, the software re-injection package comprises a plurality of sub-packets, and the synchronous storage of the software re-injection package into each re-injection package cache comprises:

[0017] For each sub-packet, the frame header, length, data and cyclic redundancy check value of the sub-packet are checked respectively.

[0018] If the check of any check item fails, the sub-packet is regarded as an abnormal sub-packet, and a retransmission request of the abnormal sub-packet is sent to a ground control center.

[0019] If the check of all check items passes, the sub-packet is synchronously stored into each re-injection package cache, wherein each sub-packet in the same software re-injection package is sequentially stored in the re-injection package cache.

[0020] Further, the comparison and verification of the cache data of the same software re-annotation package in different re-annotation package caches comprises:

[0021] For any software re-annotation package, the cache data of the software re-annotation package is extracted from each re-annotation package cache, and the cache data comprises sub-cache data of each sub-data packet in the software re-annotation package;

[0022] For each sub-data packet, the sub-cache data taken from different re-annotation package caches is compared, and if the sub-cache data in at least two re-annotation package caches is the same, it is determined that the comparison and verification of the sub-cache data is passed, and if the sub-cache data in each re-annotation package cache is different, it is determined that the comparison and verification of the sub-cache data is failed;

[0023] If the comparison and verification of any sub-data packet in the cache data is failed, it is determined that the comparison and verification of the cache data is failed, and if the comparison and verification of all sub-data packets in the cache data is passed, it is determined that the comparison and verification of the cache data is passed;

[0024] The comparison and verification of the cache data according to the comparison and verification of the cache data of the same software re-annotation package in different re-annotation package caches comprises:

[0025] Any cache data that passes the comparison and verification is taken as a to-be-downloaded re-annotation package.

[0026] Further, after the comparison and verification of the cache data of the same software re-annotation package in different re-annotation package caches, the method further comprises:

[0027] In the case that the cache data in any re-annotation package cache fails the verification, the abnormal frequency of the re-annotation package cache is updated;

[0028] Before the main control device receives the software re-annotation package of the plurality of to-be-re-annotated devices transmitted by the ground control center, the method further comprises:

[0029] In response to the software re-annotation instruction, the abnormal frequency of each re-annotation package cache in the main control device is called, and if the abnormal frequency is greater than a preset frequency threshold, a main-backup control switching request is generated and sent to a target satellite, so that the execution subject of the reception and the download of the software re-annotation package is switched from the main control device to a backup control device through the target satellite, wherein the connection relationship of the backup control device with each single machine device and the configuration of the re-annotation package cache are the same as those of the main control device, and the backup control device is used to download the to-be-downloaded re-annotation package to any single machine device and the main control device.

[0030] Further, the main control device is configured with a main control refresh chip and a main control program cache, the single machine device is configured with a single machine refresh chip and a single machine program cache, and is not configured with a re-annotation package cache;

[0031] The on-orbit reloading of the program cache of the to-be-reloaded device by the refreshing chip comprises:

[0032] In the case that the to-be-reloaded device is a master control device or a standby master control device, on-orbit reloading is performed by the master control refreshing chip and the master control program cache according to the to-be-downloaded reloading package;

[0033] In the case that the to-be-reloaded device is a single machine device, on-orbit reloading is performed by the single machine refreshing chip and the single machine program cache according to the to-be-downloaded reloading package.

[0034] According to another aspect of the present application, a device for on-orbit reloading of a plurality of satellite-borne device units is provided, comprising:

[0035] A transmission module is configured to receive, in response to a software reloading instruction, a plurality of software reloading packages of to-be-reloaded devices transmitted by a ground control center, wherein the master control device comprises at least three reloading package caches, and the to-be-reloaded devices comprise master control devices and single machine devices;

[0036] A cache module is configured to store the software reloading packages in the reloading package caches synchronously;

[0037] A verification module is configured to perform comparison verification on the cache data of the same software reloading package in different reloading package caches, and generate a to-be-downloaded reloading package according to the cache data that passes the comparison verification;

[0038] A reloading module is configured to download the to-be-downloaded reloading package to the refreshing chip of the corresponding to-be-reloaded device, so as to perform on-orbit reloading of the program cache of the to-be-reloaded device by the refreshing chip.

[0039] According to still another aspect of the present application, a system is provided, comprising a master control device, a standby master control device and a plurality of single machine devices, wherein the connection relationship of the standby master control device with each single machine device and the configuration of the reloading package 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 reloading package caches, a master control refreshing chip and a master control program cache, the single machine device is configured with a single machine refreshing chip and a single machine program cache, and is not configured with a reloading package cache;

[0040] The field programmable gate array of the master control device is configured to perform the operations corresponding to the on-orbit reloading method of the plurality of satellite-borne device units;

[0041] The single machine device is configured to perform on-orbit reloading by the single machine refreshing chip and the single machine program cache according to the to-be-downloaded reloading package;

[0042] 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.

[0043] By employing the above-described technical solutions, the technical solutions provided by the embodiments of the present invention have at least the following advantages:

[0044] 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 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.

[0045] 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

[0046] 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:

[0047] 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;

[0048] Figure 2 This diagram illustrates a system hardware architecture block diagram provided by an embodiment of the present invention.

[0049] Figure 3 This diagram illustrates a block diagram of a main control FPGA software architecture provided by an embodiment of the present invention.

[0050] Figure 4This diagram illustrates a block diagram of a single-machine FPGA software architecture provided by an embodiment of the present invention.

[0051] 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

[0052] 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.

[0053] 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 send 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:

[0054] 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.

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

[0056] 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.

[0057] 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.

[0058] 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.

[0059] 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.

[0060] 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:

[0061] 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.

[0062] 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.

[0063] 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. 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, at lower orbital altitudes, the link rate can be appropriately increased. Therefore, calculating the link rate used for software re-injection package transmission based on the software re-injection package size, satellite telemetry and control angle, and orbital altitude parameters allows for adaptive link rate adjustments based on the real-time environment, ensuring complete and reliable data transmission.

[0064] Specifically, the formula for calculating the adaptive link rate can be expressed as:

[0065] ;

[0066] 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 from the target satellite.

[0067] 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:

[0068] For each sub-data packet, the frame header, length, data, and cyclic redundancy check value of the sub-data packet are checked separately.

[0069] 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.

[0070] If all verification items pass the verification, the sub-data packet is synchronously stored in each of the re-injection packet caches.

[0071] 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.

[0072] 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.

[0073] 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.

[0074] 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:

[0075] 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;

[0076] 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.

[0077] 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.

[0078] The method of generating a re-injection package based on cached data through comparison and verification includes:

[0079] Any cached data that passes the comparison and verification will be used as the re-injection package to be sent.

[0080] 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.

[0081] 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:

[0082] If the cached data in any re-betting package cache fails the verification, update the abnormal frequency of the re-betting package cache;

[0083] 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:

[0084] 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.

[0085] 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.

[0086] 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.

[0087] 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;

[0088] The step of performing on-orbit re-injection of the program cache of the device to be re-injected through the refresh chip includes:

[0089] 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.

[0090] 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.

[0091] 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.

[0092] 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.

[0093] 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)).

[0094] 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).

[0095] 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.

[0096] 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.

[0097] 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.

[0098] 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.

[0099] 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.

[0100] 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.

[0101] 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.

[0102] 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:

[0103] 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;

[0104] Cache module 32 is used to synchronously store the software re-injection package into each of the re-injection package caches;

[0105] 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.

[0106] 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.

[0107] 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.

[0108] Furthermore, the device also includes:

[0109] 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.

[0110] 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.

[0111] 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.

[0112] 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.

[0113] Furthermore, the cache module 32 includes:

[0114] The verification unit is used to verify the frame header, length, data, and cyclic redundancy check value of each sub-data packet.

[0115] 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.

[0116] 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.

[0117] Furthermore, the verification module 33 includes:

[0118] 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;

[0119] 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.

[0120] 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.

[0121] 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.

[0122] Furthermore, the device also includes:

[0123] 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.

[0124] 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:

[0125] 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. This allows the execution entity for receiving and sending software re-injection packages to be switched 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, as well as 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.

[0126] Furthermore, the re-injection module includes:

[0127] 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.

[0128] 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.

[0129] 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.

[0130] 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;

[0131] 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.

[0132] 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.

[0133] 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.

[0134] 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-betting package to be sent is sent to the refresh chip of the corresponding re-betting device, so that the program cache of the re-betting device can be re-betted in orbit through the refresh chip; 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 master 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.

2. The on-orbit refueling method for multi-satellite equipment units according to claim 1, 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.

3. 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.

4. The on-orbit refueling method for multi-satellite equipment units according to claim 3, characterized in that, The comparison and verification of cached data for 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 method of generating a re-injection package based on cached data through comparison and verification includes: Any cached data that passes the comparison and verification will be used as the re-injection package to be sent.

5. 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.

6. The on-orbit refueling method for multi-satellite equipment units according to claim 5, 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.

7. An on-orbit refueling device for a multi-spaceborne equipment unit, characterized in that, The 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-5, including: 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.

8. 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-5; 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