Satellite-borne software efficient autonomous reconstruction method for constellation network system

Abstract

The application belongs to the field of reconstruction methods, and particularly relates to a kind of high-efficiency autonomous reconstruction method of satellite-borne software facing constellation network system.A kind of autonomous reconstruction method of satellite-borne software facing constellation network system, wherein, including the following steps: step one: satellite node partition configuration;Step two: constellation autonomous reconstruction scheme.The application has the following beneficial effects relative to prior art:(1) the application realizes the uniformity of software version in constellation, and only needs to make a version of reconstruction file when reconstructing constellation;(2) when reconstructing constellation, only needs to use the injection of star-ground TT&C link once, and the reconstruction of satellite node will be completed autonomously with the aid of inter-satellite network, saving the valuable TT&C arc segment resource;(3) the satellite node outside the visible arc segment can be reconstructed, simplifying the task amount of constellation reconstruction and improving the efficiency.

Description

Technical Field

[0001] This invention pertains to reconstruction methods, specifically a method for efficient and autonomous reconstruction of onboard software for constellation network systems. Background Technology

[0002] A satellite constellation consists of one or more groups of satellites launched into orbit and functioning normally. The satellite nodes within the constellation interconnect with each other via an inter-satellite network, thus forming the entire constellation network system, such as the BeiDou Navigation Satellite System. Generally, in a constellation system, the functions of each node satellite are completely identical, except for differences in configuration parameters.

[0003] Traditional onboard software typically compiles satellite configuration parameters and function codes together to generate binary image files. Once the parameters change, even if the functions are exactly the same, the generated binary image files will be different. This tight coupling of parameters and functions produces a large number of redundant reconstruction files. When some satellites in the constellation need to be reconstructed, the traditional approach can only use the inefficient method of single-satellite uploading and single-satellite reconstruction (i.e., uploading and reconstructing one satellite at a time).

[0004] The limitations of the traditional reconstruction mode are very obvious, mainly in three aspects: (1) During reconstruction, a binary image file needs to be made for each satellite, and the large number of files brings great difficulties to version control; (2) For constellation reconstruction, the single-satellite uploading and single-satellite reconstruction mode brings a huge workload to maintenance personnel; (3) Single-satellite uploading and single-satellite maintenance require the use of valuable satellite-ground telemetry and control arcs, and it is impossible to reconstruct satellites outside the visible arc, which is extremely inefficient. Taking the Beidou navigation constellation as an example, there are about 50 satellites in orbit. If 30 of them need to be reconstructed, then 30 reconstruction files need to be made on the ground, and ground maintenance personnel need to upload them 30 times through the satellite-ground link. During the maintenance process, it is also necessary to consider a series of issues such as whether the satellite is within the visible arc range, which is extremely labor-intensive and inconvenient. When the number of satellites in the constellation expands to hundreds or thousands, the traditional reconstruction mode will amplify the above defects proportionally.

[0005] In summary, since the existing technical model can only be used for single-star betting and single-star upgrades, it directly leads to problems such as a surge in workload, maintenance difficulties, and low efficiency when facing constellation reconstruction, making it difficult to implement in practice. Summary of the Invention

[0006] The purpose of this invention is to address the shortcomings of existing technologies by providing an efficient and autonomous reconfiguration method for onboard software in constellation network systems.

[0007] The specific technical solution adopted in this invention is as follows: A method for autonomous reconfiguration of onboard software for constellation network systems, comprising the following steps:

[0008] Step 1: Satellite node partition configuration;

[0009] Step Two: Constellation Autonomous Reconstruction Scheme.

[0010] The above-described method for autonomous reconfiguration of onboard software in a constellation network system further includes step three: rollback.

[0011] If the satellite fails to start, the boot software will obtain the current software image version number from the boot parameter area, infer the previous version number, calculate the previous version's loading address, and reload the previous version's program.

[0012] As described above, in the autonomous reconfiguration method for onboard software in a constellation network system, the satellite server is a randomly selected node satellite within the territory. Once selected, this satellite will serve as the satellite server throughout the current reconfiguration mission until the constellation reconfiguration mission ends. In the next constellation reconfiguration, any satellite node can become the satellite server.

[0013] The above-described method for autonomous reconfiguration of onboard software in a constellation network system includes, in step one, the following:

[0014] The satellite's hardware is configured according to current integrated electronic standards, namely ROM+FLASH / EEPROM+SRAM. ROM is used to store the boot software image, FLASH / EEPROM is used to store boot parameters, configuration parameters and software image, and SRAM is the program execution area. In the constellation, the satellite nodes are interconnected through an inter-satellite network to form a constellation network system.

[0015] The above-described method for autonomous reconfiguration of onboard software for constellation network systems includes a node satellite memory partitioning configuration based on the following principles: the FALSH / EEPROM is configured into three partitions: a boot parameter partition, a satellite parameter partition, and a software image partition. The software image partition is further subdivided into several smaller partitions, each with the same space capacity, used to store different versions of the software image. The number of partitions should be flexibly set according to the size of the software image and the capacity of the FALSH / EEPROM.

[0016] The above-described method for autonomous reconfiguration of onboard software in a constellation network system includes, in step two, the following:

[0017] (1) Determine the list of satellites in the constellation that need to be reconstructed;

[0018] (2) Select one satellite located within the territory as the satellite server, upload the reconstruction file to the satellite server, and upload the list of satellite nodes that need to be reconstructed.

[0019] (3) The satellite server verifies the reconstruction file. If the verification fails, it notifies the ground to re-upload the reconstruction file. If the verification passes, the satellite server obtains the relevant satellite information based on the reconstruction list and uses it as the node to be upgraded.

[0020] (4) The satellite server segments and packages the reconstructed file data into network data packets and sends the network data packets to the satellite to be upgraded.

[0021] (5) When the satellite to be reconstructed receives the reconstruction data packet, it first caches the data in its local SRAM. After the satellite server has sent all the reconstruction data, it continues to send reconstruction instructions to the satellite, and the satellite begins reconstruction. During the reconstruction process, the satellite sends reconstruction status messages to the satellite server.

[0022] (6) If the satellite server receives a message that the satellite maintenance is successful, it selects the next satellite to be reconstructed in the upgrade list as the current satellite node to be reconstructed, and repeats the process of steps (4) to (6). If the satellite server receives a message that the satellite maintenance is unsuccessful, it repeats the process of steps (5) to (6). If a certain node satellite fails to be reconstructed three times in a row, the satellite server abandons the constellation upgrade task and transmits the failure information to the ground.

[0023] The above-described method for autonomous reconfiguration of onboard software in a constellation network system includes a satellite reconfiguration process that begins according to the following steps.

[0024] Step A. The satellite verifies the reconstructed data cached in the local SRAM. If the verification passes, proceed to Step B. If it fails, send a verification failure message to the satellite server and exit the current reconstruction process.

[0025] Step B. The satellite obtains parameters from the software image area: reconstructs the software storage address and erases multiple sectors starting from this address. The number of sectors erased is equal to the number of sectors occupied by the software image. If the erasure is successful, proceed to step C. If it fails, exit the current reconstruction process and wait for the next reconstruction instruction.

[0026] Step C. The satellite writes the data cached in the local SRAM into the reconstruction file area starting from the software storage address. If the writing is successful, proceed to step D. If it fails, exit the current reconstruction process and wait for the next reconstruction instruction.

[0027] Step D. The satellite reads the reconstructed data written to the software image area and verifies it. If it is correct, the reconstruction is successful and the data written to the memory is correct. Then proceed to step E. If it fails, exit the current reconstruction process and wait for the next reconstruction instruction.

[0028] Step E. Update the parameters in the boot parameter area, set the startup software version to the reconstructed version, increment the version number by 1, update the reconstructed software address and software storage address to: software storage address + number of sectors occupied by the software image * sector capacity, and send a reconstruction success message to the satellite server. After that, the satellite will be reset and restarted, and the satellite will start running from the upgraded version.

[0029] The present invention has the following advantages over the prior art: (1) The present invention achieves unified software version within the constellation. During constellation reconstruction, only one version of the reconstruction file needs to be made. (2) During constellation reconstruction, only one uploading is required using the satellite-to-ground telemetry and control link. The reconstruction of satellite nodes will be completed autonomously with the help of the inter-satellite network, saving valuable telemetry and control arc resources. (3) Satellite nodes outside the visible arc can be reconstructed, simplifying the workload of constellation reconstruction and improving efficiency. (4) The method given by the present invention can decouple satellite software logic and configuration parameters, so that satellites with the same function but different parameters can share a single version of the software image file, ensuring the uniformity of software within the constellation. (5) The method given by the present invention can achieve the function of uploading a single satellite once and autonomously upgrading the constellation. Compared with the traditional reconstruction mode, it greatly reduces the workload of constellation reconstruction and does not need to consider whether the reconstructed satellite is within the visible arc range, making the operation more convenient and the maintenance process safer. (6) The method given by the present invention has the function of autonomously reverting to the previous version of the software when reconstruction fails, ensuring the reliability of satellite operation. Attached Figure Description

[0030] Figure 1 Constellation Network System Architecture Diagram

[0031] Figure 2 Node satellite storage partition configuration diagram

[0032] Figure 3 Constellation Network Connection Diagram

[0033] Figure 4 Constellation Self-Reconstruction Flowchart Detailed Implementation

[0034] This invention provides a method for autonomous reconfiguration of onboard software for constellation network systems. The specific implementation method is described in detail below with reference to the accompanying drawings.

[0035] 1. Satellite node partition configuration

[0036] First, the satellite's hardware is configured according to current integrated electronic standards, namely ROM + FLASH / EEPROM + SRAM. ROM stores the boot software image, FLASH / EEPROM stores boot parameters, configuration parameters, and the software image, and SRAM is the program execution area. Within the constellation, the satellite nodes are interconnected through an inter-satellite network to form the constellation network system.

[0037] This section is based on Figure 2 This example illustrates how the method provided in this invention can be used to decouple satellite software and parameters within a constellation, ultimately enabling all satellite nodes within the constellation to share a single software image file.

[0038] Figure 2 This diagram illustrates the partitioning configuration for the node satellite memory. To decouple software from parameters, the FALSH / EEPROM is configured with three partitions: a boot parameter area, a satellite parameter area, and a software image area.

[0039] The boot parameter area mainly stores key parameters when the boot software loads the software image. The boot parameter settings are as follows:

[0040]

[0041] The satellite parameter area mainly stores the satellite's inherent parameter information, such as satellite number and satellite node number. The satellite parameter settings are shown below:

[0042]

[0043] The software image area is used to store various versions of the software image. The software image area is divided into several smaller partitions, each with the same space capacity, and each partition is used to store different versions of the software image. The number of smaller partitions in the software image area should be flexibly set according to the size of the software image and the capacity of the FALSH / EEPROM.

[0044] Following the above partitioning strategy, different types of data are stored in partitions, achieving separation of satellite software and parameters. If a satellite requires reconstruction, after modifying the code, the compiled image files are completely consistent across different satellite nodes. Satellite parameter settings have no impact on the image files, thus ensuring consistency across all software image files in the constellation and achieving uniformity of satellite software across all nodes.

[0045] 2. Constellation Autonomous Reconstruction Scheme

[0046] Figure 3 This is a diagram illustrating the connections within a constellation network. For ease of description, Figure 3The paper presents a typical link in a constellation network route (i.e., an inter-satellite link consisting of satellites s, k, j, and f). The upgrade method for other node satellites in the constellation network is the same as that for this link, and will not be repeated here.

[0047] Figure 4 The flowchart for the autonomous reconfiguration of the constellation consists of two parts: the satellite server and the node satellite. The two operate independently and interact with each other through inter-satellite links to exchange reconfiguration data commands and reconfiguration status information.

[0048] This section is based on Figure 3 Taking one inter-satellite link as an example, and combining it with... Figure 4 The flowchart details how to use the method provided in this invention to achieve the function of one-time software betting and autonomous constellation upgrade. The autonomous constellation reconstruction process is carried out according to the following steps:

[0049] (1) Determine the list of satellites in the constellation that need to be reconstructed, assuming that the satellites at each node have already been reconstructed according to... Figure 2 By configuring partitions, the software and parameters are decoupled, so during reconstruction, only one reconstruction file needs to be created for the ground.

[0050] (2) Select one satellite located within the territory as the satellite server, such as Figure 3 Satellite s in the system uploads the reconstruction file to satellite server s via the satellite-to-ground link, along with the list of node satellites that need to be reconstructed.

[0051]

[0052] (3) The satellite server verifies the reconstruction file. If the verification fails, it notifies the ground to re-upload the reconstruction file. If the verification passes, the satellite server obtains the SCID, IP, and NODE_ID of satellite 0 from the reconstruction list, using this information as the node to be upgraded. Figure 4 In the current context, the satellite node awaiting upgrade is satellite f.

[0053] (4) The satellite server segments and packages the reconstructed file data into network data packets and sends these network data packets to the satellite f to be upgraded. Figure 3 In the process, the satellite server, using the inter-satellite network, establishes a TCP connection with satellite f through node satellites j and k, and sends network data packets to satellite f:

[0054] (5) When the satellite f to be reconstructed receives the reconstruction data packet, it first caches the data in its local SRAM. After the satellite server finishes sending all the reconstruction data, it continues to send reconstruction instructions to satellite f. Satellite f then begins to reconstruct the FLASH / EEPROM according to the following steps. During the reconstruction process, satellite f sends a reconstruction status message to the satellite server (the entire reconstruction begins at the reconstruction software address NEXT_ADDR in the software image area and has no impact on the existing software image):

[0055] A. The satellite verifies the reconstructed data cached in the local SRAM. If the verification passes, proceed to B. If it fails, send a verification failure message to the satellite server and exit the current reconstruction process.

[0056] B. Satellite f obtains parameters from the software image area: reconstructs the software storage address NEXT_ADDR and erases SECTOR_N sectors starting from this address; if the erasure is successful, then proceed to C; if it fails, then exit the current reconstruction process and wait for the next reconstruction instruction.

[0057] C. Satellite f writes the data cached in the local SRAM into the reconstruction file area starting from NEXT_ADDR. If the write is successful, then proceed to D. If it fails, then exit the current reconstruction process and wait for the next reconstruction instruction.

[0058] D. Satellite f reads the reconstructed data written to the software image area and verifies it. If it is correct, the reconstruction is successful and the data written to the memory is correct. Then proceed to E. If it fails, exit the current reconstruction process and wait for the next reconstruction instruction.

[0059] E. Update the parameters in the boot parameter area, set the boot software version BOOT_ID to the reconstructed version, increment the version number VER_N by 1, update the reconstructed software address NEXT_ADDR to NEXT_ADDR+SECTOR_N*SECTOR_SIZE, and send a reconstructed success message to the satellite server. After that, the satellite f is reset. After restarting, the satellite will start running from the upgraded version.

[0060] (6) If the satellite server receives a message that satellite f has been successfully maintained, it selects the next satellite to be reconstructed in the upgrade list as the current satellite node f to be reconstructed, and repeats the process of steps (4) to (6). If the satellite server receives a message that satellite f has failed to be maintained, it repeats the process of steps (5) to (6). If a certain node satellite fails to be reconstructed three times in a row, the satellite server abandons the constellation upgrade task and transmits the failure information to the ground.

[0061] It should be noted that the satellite server is a randomly selected node satellite within the territory. Once selected, this satellite will serve as the satellite server throughout the current reconfiguration mission until the constellation reconfiguration is completed. In the next constellation reconfiguration, any satellite node can become the satellite server.

[0062] 3. Design of Autonomous Backoff Strategy

[0063] As described in the constellation autonomous reconfiguration strategy in step 2 above, after the node satellite completes the upgrade according to step (5), the reconfigured node satellite will reset and restart to run the reconfigured software. Under this condition, there may be a situation that causes the software to fail to start. That is, if the software passes the rigorous layer-by-layer verification of step (5) and the reconfiguration is completed, the node satellite fails to start from the reconfigured software after the reset. After going through step (5), although the probability of this phenomenon is extremely low, in order to avoid this situation, this paper designs a rollback strategy. When the software is reset, if the startup fails, the boot software will obtain the current software image version number VER_N from the boot parameter area, and infer the previous version number based on this, calculate the loading address of the previous version, and reload the program of the previous version, thereby realizing the version rollback and ensuring the normal operation of the software. The specific process is as follows:

[0064]

[0065] In the above scenarios, the method provided by this invention decouples the software from the parameters, enabling the use of a single version of software by node satellites in the constellation and ensuring the universality of the onboard software. Simultaneously, through the constellation network system, the function of "one-time software upload and autonomous constellation upgrade" is achieved, greatly reducing the workload of constellation reconstruction and allowing reconstruction of node satellites outside the visible arc. During constellation reconstruction, a safe and reliable reconstruction process and version rollback function are designed to ensure the safety and reliability of reconstructing constellation node satellites.

Claims

1. A method for autonomous reconfiguration of onboard software for constellation network systems, characterized in that, Includes the following steps: Step 1: Satellite node partition configuration; Step Two: Constellation Autonomous Reconstruction Scheme; The method also includes step three: If the satellite fails to start, the boot software will obtain the current software image version number from the boot parameter area, infer the previous version number, calculate the loading address of the previous version, and reload the program of the previous version. Step two includes the following: (1) Determine the list of satellites in the constellation that need to be reconstructed; (2) Select one satellite located within the territory as the satellite server, upload the reconstruction file to the satellite server, and upload the list of satellite nodes that need to be reconstructed. (3) The satellite server verifies the reconstruction file. If the verification fails, it notifies the ground to re-upload the reconstruction file. If the verification passes, the satellite server obtains the relevant satellite information based on the reconstruction list and uses it as the node to be upgraded. (4) The satellite server segments and packages the reconstructed file data into network data packets and sends these network data packets to the satellite to be upgraded. (5) When the satellite to be reconstructed receives the reconstruction data packet, it first caches the data in its local SRAM. After the satellite server has sent all the reconstruction data, it continues to send reconstruction instructions to the satellite, and the satellite begins reconstruction. During the reconstruction process, the satellite sends reconstruction status messages to the satellite server. (6) If the satellite server receives a message that the satellite maintenance is successful, it selects the next satellite to be reconstructed in the upgrade list as the current satellite node to be reconstructed, and repeats the process of steps (4) to (6). If the satellite server receives a message that satellite maintenance has failed, then repeat steps (5) to (6). If a certain node satellite fails to reconstruct three times in a row, then the satellite server abandons the constellation upgrade task and transmits the failure information to the ground. The satellite reconfiguration process begins as follows: Step A. The satellite verifies the reconstructed data cached in the local SRAM. If the verification passes, proceed to Step B. If it fails, send a verification failure message to the satellite server and exit the current reconstruction process. Step B. The satellite obtains parameters from the software image area: reconstructs the software storage address and erases multiple sectors starting from this address. The number of sectors erased is equal to the number of sectors occupied by the software image. If the erasure is successful, proceed to step C. If it fails, exit the current reconstruction process and wait for the next reconstruction instruction. Step C. The satellite writes the data cached in the local SRAM into the reconstruction file area starting from the software storage address. If the writing is successful, proceed to step D. If it fails, exit the current reconstruction process and wait for the next reconstruction instruction. Step D. The satellite reads the reconstructed data written to the software image area and verifies it. If it is correct, the reconstruction is successful and the data written to the memory is correct. Then proceed to step E. If it fails, exit the current reconstruction process and wait for the next reconstruction instruction. Step E. Update the parameters in the boot parameter area, set the startup software version to the reconstructed version, increment the version number by 1, update the reconstructed software address and software storage address to: software storage address + number of sectors occupied by the software image * sector capacity, and send a reconstruction success message to the satellite server. After that, the satellite will be reset and restarted, and the satellite will start running from the upgraded version.

2. The method for autonomous reconfiguration of onboard software for constellation network systems as described in claim 1, characterized in that: The satellite server is a randomly selected node satellite within the territory. Once selected, the satellite will serve as the satellite server in this reconstruction mission until the constellation reconstruction mission is completed. In the next constellation reconstruction, any satellite node can become the satellite server.

3. The method for autonomous reconfiguration of onboard software for constellation network systems as described in claim 2, characterized in that: Step one includes the following: The satellite's hardware is configured according to current integrated electronic standards, namely ROM+FLASH / EEPROM+SRAM. ROM is used to store the boot software image, FLASH / EEPROM is used to store boot parameters, configuration parameters and software image, and SRAM is the program execution area. In the constellation, the satellite nodes are interconnected through an inter-satellite network to form a constellation network system.

4. The method for autonomous reconfiguration of onboard software for constellation network systems as described in claim 3, characterized in that: The node satellite memory partitioning configuration follows the principles below, setting the FALSH / EEPROM into three partitions: boot parameter area, satellite parameter area, and software image area. The software image area is further subdivided into several smaller partitions, each with the same space capacity, used to store different versions of the software image. The number of partitions should be flexibly set according to the size of the software image and the capacity of the FALSH / EEPROM.

Images