On-satellite data reconstruction method and system and computer readable medium

Abstract

The invention relates to an on-satellite data reconstruction method and system and a computer readable medium, and the method comprises the steps: a ground station generates a reconstructed uploading data frame according to an uploading file and an uploading data frame format; the ground station uploads the upload data frame to a satellite; the satellite carries out correctness verification on the top pouring data frame, carries out integrity verification on the top pouring data frame, and remotely sends the reconstruction state of the top pouring data frame to the ground station; and in response to passing of the correctness verification and the integrity verification, the satellite reloads the top-pouring data frame according to a preset top-pouring data reloading method. According to the method and the device, on-satellite data can be automatically transmitted in a breakpoint manner under the condition that the satellite-ground transmission channel is abnormal or occupied, so that the reconstruction efficiency of the on-satellite data is improved, the operation requirement of a satellite constellation can be met, and the labor cost is reduced.

Description

Technical Field

[0001] This application mainly relates to the field of satellite control technology, and specifically relates to an on-board data reconstruction method, system and computer-readable medium. Background Art

[0002] To cope with more complex mission scenarios and broader time-domain requirements, large-batch and low-cost satellite constellations have become the mainstream solution in the current space field. The number of satellite constellations operating in Low Earth Orbit (LEO) reaches the order of tens of thousands, which poses requirements such as shorter R & D cycle, lower cost, and more convenient software update for on-board single units. The convenient software update of on-board product single units can make the satellite constellation more flexible, diverse and intelligent.

[0003] Currently, the software update of on-board product single units mainly relies on the staff of the ground station. For example, in the case of abnormal or occupied space-ground transmission channels, data needs to be retransmitted manually, and the efficiency of on-board data reconstruction is low, which cannot meet the operation requirements of satellite constellations. Summary of the Invention

[0004] The technical problems to be solved by this application are to provide an on-board data reconstruction method, system and computer-readable medium, which can automatically resume interrupted transmission of on-board data in the case of abnormal or occupied space-ground transmission channels, improve the efficiency of on-board data reconstruction, meet the operation requirements of satellite constellations, and reduce labor costs.

[0005] The technical solution adopted by this application to solve the above technical problems is an on-board data reconstruction method, including: the ground station generates a reconstructed uplink data frame according to the uplink file and the uplink data frame format; the ground station uploads the uplink data frame to the satellite; the satellite performs a correctness check on the uplink data frame, performs an integrity check on the uplink data frame, and telemeters the reconstruction status of the uplink data frame to the ground station; in response to passing the correctness check and the integrity check, the satellite reloads the uplink data frame according to a preset uplink data reloading method.

[0006] In an embodiment of this application, the ground station generates a reconstructed uplink data frame according to the uplink file and the uplink data frame format, including: constructing the uplink file into binary bitstream data; splitting the binary bitstream data according to a preset data frame length to obtain split data; performing a first encapsulation on the split data according to the uplink data frame format to obtain first encapsulated data; performing a second encapsulation on the first encapsulated data according to a preset space-ground forward link transmission protocol to obtain second encapsulated data, and taking the second encapsulated data as the uplink data frame.

[0007] In one embodiment of the present application, the number of uplink data frames is multiple; the ground station uplinks the uplink data frames to the satellite; the satellite performs a correctness check on the uplink data frames, performs an integrity check on the uplink data frames, and telemeters the reconstruction status of the uplink data frames to the ground station, including: Step S201: The ground station sequentially uplinks the remaining uplink data frames except the last uplink data frame to the satellite; the satellite performs a correctness check on the uplink data frames, and saves the uplink data frames that pass the correctness check and discards the uplink data frames that do not pass the correctness check; Step S202: The ground station uplinks the last uplink data frame to the satellite; the satellite performs an integrity check on the uplink data frame, and if it passes the integrity check, proceeds to Step S203; or, if it does not pass the integrity check, the ground station determines the frame loss situation based on the reconstruction status telemetry and performs a frame filling operation, and then proceeds to Step S201; Step S203: The satellite performs a packet assembly operation on the saved uplink data frames to generate a complete reconstructed data frame, and uses the complete reconstructed data frame as the reloaded uplink data frame.

[0008] In one embodiment of the present application, the satellite reloads the uplink data frames according to a preset uplink data reloading method, including: parsing the uplink data frames to obtain the reconstruction code; erasing the original code in the code area of the satellite's FLASH; writing the reconstruction code into the code area of the FLASH; and transferring the reconstruction code in the FLASH to the satellite's SRAM according to the computer soft reset instruction of the ground station, so as to reload the uplink data frames.

[0009] In one embodiment of the present application, the satellite reloads the uplink data frames according to a preset uplink data reloading method, including: parsing the uplink data frames to obtain the reconstruction code; stopping and deleting the original application program in the satellite's operating system; transferring the reconstruction code to the operating system; and using the reconstruction code as the latest application program and restarting the latest application program, so as to reload the uplink data frames.

[0010] In one embodiment of the present application, the satellite performs a correctness check on the uplink data frames, including: using the satellite-ground communication data protocol to obtain the starting position of the uplink data frames according to the synchronization header; obtaining the ending position of the uplink data frames according to the data length; and determining whether the uplink data frames are valid according to the check field.

[0011] In one embodiment of the present application, the number of uplink data frames is multiple; performing an integrity check on the uplink data frames, including: sequentially splicing the frame numbers of the uplink data frames to obtain the spliced frame number; if the frame number of the last uplink data frame is equal to the number of uplink data frames, then the integrity check is passed; or if the frame number of the last uplink data frame is not equal to the number of uplink data frames, then the integrity check is not passed; obtaining the frame numbers of the lost data frames according to the spliced frame number, and telemetering the frame numbers of the lost data frames to the ground station through the reconstruction status telemetry.

[0012] In an embodiment of the present application, in the format of the upload data frame: the first byte is the frame type, and the frame type includes the first reconstructed data, intermediate reconstructed data, and the last reconstructed data; the second byte is the frame sequence number.

[0013] In an embodiment of the present application, the data structure of the reconstruction status telemetry includes: the current upload status, the upload frame transceiver status, the frame loss situation, and the received frame display; wherein, the current upload status includes any one of upload start, upload in progress, upload end, and upload completed; the upload frame transceiver status includes: the frame sequence number of the latest upload data frame received by the satellite and the number of upload data frames; the frame loss situation includes: the frame sequence numbers of the lost data frames recorded by the satellite; the received frame display includes: the first bit flag and the second bit flag; in the initial state, the satellite has the first bit flag; when the satellite receives an upload data frame, the first bit flag is set to the second bit flag.

[0014] In an embodiment of the present application, the data structure of the second encapsulated data includes: a frame header for synchronizing the frame header position; a frame main header and a frame secondary header for jointly determining the upload data channel and the data destination; an instruction execution time for judging the execution time of the instruction; an instruction code for distinguishing different instructions of the same on-board single machine; valid data for recording data; and a checksum for judging whether the data frame is correct.

[0015] The present application also proposes an on-board data reconstruction system to solve the above technical problems, including: a memory for storing instructions executable by a processor; the processor for executing the instructions to implement the above on-board data reconstruction method.

[0016] The present application also proposes a computer-readable medium storing computer program code, and the computer program code implements the above on-board data reconstruction method when executed by a processor.

[0017] The technical solution of the present application realizes the data reconstruction and update process from the ground station to the satellite. After the ground station generates the reconstructed upload data frame and uploads it to the satellite, the satellite ensures the accuracy and integrity of the received data by verifying the upload data frame; by sending the reconstruction status telemetry to the ground station, it is convenient for the ground station to master the data transmission and reconstruction situation; if the upload data frame passes the verification, the satellite will reload the upload data frame to ensure that the on-board system can perform subsequent operations based on accurate and complete reconstructed data, which can effectively maintain and update the on-board data and improve the operation efficiency of the satellite.

[0018] This application is equivalent to a method for on-orbit data reconstruction that supports resume from breakpoint, that is, a general method for on-orbit data breakpoint resume of deserialization. It can automatically resume the on-orbit data breakpoint during abnormal or occupied space-ground transmission channels, improve the efficiency of on-orbit data reconstruction, meet the operation requirements of satellite constellations, and reduce labor costs. Brief Description of the Drawings

[0019] To make the above objects, features, and advantages of the present application more obvious and understandable, the following detailed description of the specific embodiments of the present application is provided in conjunction with the accompanying drawings, where:

[0020] Figure 1 is a flowchart of the on-orbit data reconstruction method according to an embodiment of the present application;

[0021] Figure 2 is a flowchart of the on-orbit data reconstruction method according to another embodiment of the present application;

[0022] Figure 3 is a flowchart of generating a reconstructed upload data frame according to an embodiment of the present application;

[0023] Figure 4 is a flowchart of verifying the upload data frame according to an embodiment of the present application;

[0024] Figure 5 is a flowchart of reloading the upload data frame according to an embodiment of the present application;

[0025] Figure 6 is a flowchart of reloading the upload data frame according to another embodiment of the present application;

[0026] Figure 7 is a system block diagram of the on-orbit data reconstruction system according to an embodiment of the present application. Detailed Embodiments

[0027] To make the above objects, features, and advantages of the present application more obvious and understandable, the following detailed description of the specific embodiments of the present application is provided in conjunction with the accompanying drawings.

[0028] In the following description, many specific details are set forth to facilitate a thorough understanding of the present application. However, the present application may be implemented in other ways different from those described herein. Therefore, the present application is not limited by the specific embodiments disclosed below.

[0029] As shown in the present application and the claims, unless the context clearly indicates otherwise, the words "a", "an", "one", and / or "the" are not specifically singular and may also include plural. Generally speaking, the terms "including" and "comprising" only indicate the inclusion of the steps and elements that have been clearly identified, and these steps and elements do not constitute an exclusive list. The method or device may also include other steps or elements.

[0030] In this application, flowcharts are used to illustrate the operations performed by the system according to the embodiments of this application. It should be understood that the operations before or below do not necessarily need to be executed precisely in sequence. On the contrary, various steps can be processed in reverse order or simultaneously. Also, one or more operations can be added to these processes, or one or more steps can be removed from these processes.

[0031] This application proposes a method for on-board data reconstruction, which can be applied to scenarios where on-board data is normally transmitted, and can also be applied to scenarios of resuming data transmission from a breakpoint in cases where the space-ground transmission channel is abnormal or occupied. This application can be used as a general code reconstruction method, applicable to the vast majority of on-board reconstruction scenarios, which can further improve the usability and flexibility of on-board data reconstruction, ensure system security, and improve the reconstruction efficiency. The on-board data reconstruction method of this application can run on a computer at a ground station, and can also run on an on-board computer on a satellite.

[0032] Figure 1 is a flowchart of the on-board data reconstruction method according to an embodiment of this application. Refer to Figure 1 As shown, the on-board data reconstruction method of this embodiment includes the following steps:

[0033] Step S100: The ground station generates a reconstructed upload data frame according to the upload file and the upload data frame format.

[0034] Step S200: The ground station uploads the upload data frame to the satellite; the satellite performs a correctness check on the upload data frame, performs an integrity check on the upload data frame, and telemeters the reconstruction status of the upload data frame to the ground station.

[0035] Step S300: In response to passing the correctness check and the integrity check, the satellite reloads the upload data frame according to a preset upload data reloading method.

[0036] The above steps S100 to S300 are described in detail below:

[0037] In step S100, the ground station generates a reconstructed upload data frame according to the upload file and the upload data frame format. Exemplarily, according to the upload data frame format, the upload file can be split based on ground test software to generate a reconstructed data frame of binary bit stream.

[0038] In practical applications, the upload file can be a binary bit stream file. Usually, the on-board application code itself is an executable binary bit stream file such as XX.bin or XX.out, which can be directly uploaded. However, in special cases, the original upload file needs to be converted into binary bit stream files such as XX.bin and XX.dat. Considering that the file data is composed of binary data, the data structure and core meaning will not be damaged after the file conversion.

[0039] In some embodiments, in the format of the uplink data frame: the first byte is the frame type, and the frame type includes the first reconstructed data, intermediate reconstructed data, and last reconstructed data; the second byte is the frame sequence number.

[0040] Exemplarily, the format of the uplink data frame needs to have the ability to resume interrupted transmission in case of anomalies in the satellite-ground transmission link. At the same time, it should be lightweight and flexible without adding too much redundant burden to the transmission link. For this purpose, based on the satellite-ground communication data protocol format that adapts to the actual situation, three bytes are added before the valid data (i.e., the uplink data) to distinguish the uplink status, monitor the uplink progress, and guide the next operation of the reconstruction module of the on-satellite product.

[0041] Specifically, the format convention of the uplink data frame is that the first byte is the frame type, which is used to represent three data types of the uplink data: (1) the first packet of reconstructed data; (2) intermediate reconstructed data; (3) the last packet of reconstructed data. The last two bytes are the frame sequence number, which is used to indicate the sequence number of the reconstructed data frame. When the reconstruction module of the on-satellite product receives the first packet of reconstructed data, it needs to clear the data in the reconstruction area; when it receives the last packet of reconstructed data, it starts to judge the integrity of the uplink data. The uplink data frame format designed in this application facilitates the satellite to accurately judge the stage and order of the data, which helps to efficiently perform operations such as splicing and verification during the data reconstruction process, thereby improving the accuracy and efficiency of data processing.

[0042] In some embodiments, the ground station generates a reconstructed uplink data frame according to the uplink file and the format of the uplink data frame, including:

[0043] Step S101: Construct the uplink file into binary bitstream data. For example, the uplink file can be directly converted into binary bitstream files such as XX.bin and XX.dat.

[0044] Step S102: Split the binary bitstream data according to the preset data frame length to obtain the split data.

[0045] Step S103: Perform a primary encapsulation on the split data according to the format of the uplink data frame to obtain the first encapsulated data.

[0046] Step S104: Perform a secondary encapsulation on the first encapsulated data according to the preset satellite-ground forward link transmission protocol to obtain the second encapsulated data, and use the second encapsulated data as the uplink data frame.

[0047] Exemplarily, the ground station can convert the upload file into an upload data frame that meets the requirements of space-ground transmission. By constructing the upload file into binary bitstream data, splitting it according to a preset length, and performing two encapsulations, it not only ensures that the data can adapt to the space-ground forward link transmission protocol but also meets the requirements of the upload data frame format, improving the standardization and reliability of data transmission.

[0048] In some embodiments, as shown in Table 1 below, the data structure of the second encapsulated data (i.e., the binary bitstream reconstructed data frame) includes: a frame header for synchronizing the frame header position; a frame main header and a frame sub-header for jointly determining the upload data channel and the data destination; an instruction execution time for judging the execution time of the instruction; an instruction code for distinguishing different instructions of the same on-board single machine; valid data for recording data; and a checksum for judging whether the data frame is correct.

[0049] Table 1 Data Structure of Binary Bitstream Reconstructed Data Frame

[0050]

[0051] Exemplarily, in the binary bitstream reconstructed data frame, the fixed length of each frame is 512 bytes, and if it is less than 512 bytes, it is filled with 0xE0 in hexadecimal. The data structure of the second encapsulated data designed in this application can ensure the accuracy, orderliness, and traceability of data transmission and processing on the satellite.

[0052] In step S200, the ground station uploads the upload data frame to the satellite; the satellite performs a correctness check on the upload data frame, performs an integrity check on the upload data frame, and telemeters the reconstruction status of the upload data frame to the ground station.

[0053] Exemplarily, this step S200 is equivalent to monitoring the telemetry of the reconstruction status, completing the upload of the binary bitstream reconstructed data frame based on the ground measurement and control station, and completing the correctness and integrity checks of the upload data. The correctness check and integrity check of the upload data are respectively ensured by the check field to ensure the validity of the data, and the frame type and frame sequence number of the upload data frame format to ensure the integrity of the data. In practical applications, the correctness check and integrity check of the upload data can be jointly ensured by the transmission link and the reconstruction module of the on-board product.

[0054] For the correctness of the upload data, the usual space-ground communication data protocol format includes a synchronization header, a data length, and a data check field. The synchronization header is used to find the start position of the data frame, the data length is used to judge the end position of the data, and the data check field is used to ensure the validity of the data.

[0055] For the integrity of the upload data, it can be ensured by the frame type and frame sequence number of the upload data frame format. The frame type field is used to indicate the start, middle, and end data of an upload, and the frame sequence number field is used to indicate whether the data reception of an upload is complete.

[0056] Exemplarily, the reconstruction module of the on-orbit product will cache all the upload data frames received in an upload in the reconstruction area, and start the integrity check of the upload data frames when the last packet of data is received. During the integrity check of the upload data, the frame sequence number of the last packet of data frames can be compared with the number of all frames received; if the results are equal, it means that the integrity check passes, and the reconstruction module of the on-orbit product can splice all the upload data in the order of the frame sequence number; if the results are not equal, it means that the integrity check fails, and the reconstruction module of the on-orbit product can find the position of the lost frame by comparing the frame sequence numbers of each frame of data, and send it to the ground to complete the frame filling operation.

[0057] In some embodiments, the data structure of the reconstruction status telemetry includes four parts: the current upload status, the upload frame transceiver status, the frame loss situation, and the received frame display. Among them, the current upload status includes any one of: upload start, upload in progress, upload end, and upload completed. The upload frame transceiver status includes: the frame sequence number of the latest upload data frame received by the satellite and the number of upload data frames. The frame loss situation includes: the frame sequence numbers of the lost data frames recorded by the satellite. The received frame display includes: the first bit flag (e.g., 0) and the second bit flag (e.g., 1). For example, when the satellite is in the initial state, it has the first bit flag; when the satellite receives an upload data frame, the first bit flag is set to the second bit flag. Exemplarily, the reconstruction status telemetry can enable the ground to judge the code reconstruction situation through the telemetry information sent by the satellite.

[0058] Specifically, the "current upload status" can display four states: upload start, upload in progress, upload end, and upload completed. Among them, "upload end" means that the reconstruction module of the on-orbit product has received the last packet of upload data, and "upload completed" means that the reconstruction data framing is completed and the check passes.

[0059] The "upload frame transceiver status" can display the latest upload frame sequence number and the total number of upload frames received by the reconstruction module of the on-orbit product, so as to facilitate understanding of the frame loss situation when the space-ground transmission link is abnormal.

[0060] "Frame loss situation" can show the frame sequence numbers of the lost frames found by the reconstruction module of the on-board product after integrity verification in the case of abnormal space-ground transmission link. In practical applications, there may be many lost frames in extreme cases. Therefore, the reconstruction status telemetry can appropriately select the number of frame sequence numbers of the lost frames to be sent according to the size of the telemetry volume sent. Although the telemetry sent at one time may not show all the frame sequence numbers of the lost frames, as the frame filling process progresses, the number of frame sequence numbers of the lost frames will gradually decrease, and all the frame sequence numbers of the lost frames will be displayed.

[0061] "Received frame display" can more intuitively and real-time display the situation of the received frames of the reconstruction module of the on-board product. The reception situation of the corresponding uploaded frames can be represented by 0 or 1 of the bit. For example, initially all bits will be set to 0, and when the uploaded frame at the corresponding position is received, the bit at the corresponding position will be set to 1. In this way, the reception situation of the uploaded frames and the approximate positions of the lost frames can be intuitively displayed during the uploading process. Usually, for the case of large uploaded data, "received frame display" can only take a partial number of bits as the corresponding bits of the uploaded frames, and the excess part uses the multiplexed bit method to complete the received frame display.

[0062] Exemplarily, the data structure of the reconstruction status telemetry of the present application can present the data uploading process more comprehensively for the ground station, which helps the ground station to monitor in real time and handle various situations in the on-board data reconstruction in a timely manner.

[0063] In some embodiments, the number of uploaded data frames is multiple; the ground station uploads the uploaded data frames to the satellite; the satellite performs correctness verification on the uploaded data frames, performs integrity verification on the uploaded data frames, and sends the reconstruction status telemetry of the uploaded data frames to the ground station, including:

[0064] Step S201: The ground station sequentially uploads the remaining uploaded data frames except the last uploaded data frame to the satellite; the satellite performs correctness verification on the uploaded data frames, and saves the uploaded data frames that pass the correctness verification and discards the uploaded data frames that do not pass the correctness verification;

[0065] Step S202: The ground station uploads the last uploaded data frame to the satellite; the satellite performs integrity verification on the uploaded data frame. In response to passing the integrity verification, it proceeds to execute Step S203; or, in response to not passing the integrity verification, the ground station judges the frame loss situation according to the reconstruction status telemetry and performs a frame filling operation, and proceeds to execute Step S201;

[0066] Step S203: The satellite performs packet assembly operations on the saved uploaded data frames to generate complete reconstructed data frames, and takes the complete reconstructed data frames as the reloaded uploaded data frames.

[0067] Exemplarily, the present application realizes the accurate reconstruction of on-board data by transmitting and verifying multiple uplink data frames step by step. First, the data frames except the last one are sequentially uploaded and verified for correctness to ensure the correctness of single-frame data; then the last frame is uploaded and verified for integrity, and if it fails, the frame can be supplemented in time. Finally, the correct data frames saved are packetized to generate a complete reconstructed data frame for reloading, ensuring the accuracy and integrity of on-board data reconstruction.

[0068] In some embodiments, the satellite verifies the correctness of the uplink data frame, including:

[0069] Adopt the space-ground communication data protocol to obtain the starting position of the uplink data frame according to the synchronization header;

[0070] Obtain the termination position of the uplink data frame according to the data length;

[0071] Judge whether the uplink data frame is valid according to the check field.

[0072] Exemplarily, the present application can accurately identify whether the uplink data frame is correct, provide a reliable data basis for subsequent on-board data processing and reconstruction, and ensure the quality and accuracy of data transmission.

[0073] In some embodiments, the number of uplink data frames is multiple; the integrity verification of the uplink data frame includes:

[0074] Sequentially splice the frame numbers of the uplink data frames to obtain the spliced frame number;

[0075] If the frame number of the last uplink data frame is equal to the number of uplink data frames, the integrity verification is passed; or

[0076] If the frame number of the last uplink data frame is not equal to the number of uplink data frames, the integrity verification fails; obtain the frame number of the missing data frame according to the spliced frame number, and send the frame number of the missing data frame to the ground station through the reconstruction status telemetry.

[0077] Exemplarily, the present application can quickly judge whether the uplink data frame is complete, can timely detect the situation of missing frames, provide a basis for the ground station to supplement frames, and ensure the integrity of the data required for on-board data reconstruction.

[0078] In step S300, in response to passing the correctness verification and integrity verification, the satellite reloads the uplink data frame according to the preset uplink data reloading method.

[0079] Exemplarily, step S300 of the present application is equivalent to performing an overloading operation on the refactored code according to the uploading data overloading method. Generally, the uploading data overloading method includes two parts: deletion of the original code and transfer and parsing of the refactored code. The uploading data overloading method can be designed as a separate application module on the on-board product. For different on-board products, the implementation details of the uploading data overloading method may vary, that is, the specific operation method of step S300 is different. Below, the on-board high-reliability products and on-board high-performance products will be introduced respectively.

[0080] For on-board high-reliability products such as the on-board computer, its refactoring area is generally located in SRAM (Static Random Access Memory), and the code is stored in FLASH (Flash Memory). After the uploading data passes the correctness and integrity verification, the refactoring module of the on-board product will erase the original code in the FLASH and write the refactored code in the SRAM into the FLASH. Then, according to the intervention of the ground instruction, in the form of a soft reset, the computer is required to transfer the code in the FLASH again, so as to achieve overloading.

[0081] For on-board high-performance products using the LINUX operating system, the on-board application code no longer serves as the application platform. All on-board application codes are APPs (Applications) on the operating system, with strong independence and no ability to operate the hardware. At this time, the uploading data overloading method is actually embodied as an independent APP on the on-board product operating system. The specific process is as follows: Stop the original application program through the intervention of the ground instruction, and at the same time start the overloading program. The overloading program completes the deletion of the original application program, the transfer and parsing of the refactored code, and returns the overloading situation to the ground. Finally, stop the overloading program again through the intervention of the ground instruction and restart the refactored application program to complete the uploading data overloading.

[0082] In some embodiments, for high-reliability on-board products (such as the on-board computer), the satellite overloads the uploading data frame according to the preset uploading data overloading method, including:

[0083] Step S301a: Parse the uploading data frame to obtain the refactored code;

[0084] Step S302a: Erase the original code in the code area of the satellite's FLASH;

[0085] Step S303a: Write the refactored code into the code area of the FLASH;

[0086] Step S304a: Transfer the refactored code in the FLASH to the satellite's SRAM according to the computer soft reset instruction of the ground station, so as to overload the uploading data frame.

[0087] Exemplarily, for on-board products with high reliability, the refactoring module of the on-board product application code can make certain declarations for the memory addresses in the refactoring area, and concretize binary data into specific concepts such as an effective data array and a received data flag array in the form of a structure. The method of overloading the above-injected data frame in this application helps to ensure the high-reliability operation of on-board products, ensures that they execute tasks based on the latest refactored code, and maintains and enhances the functions of the satellite system.

[0088] In some embodiments, for high-performance on-board products (such as a processing planner using the LINUX operating system), the satellite overloads the above-injected data frame according to a preset above-injected data overloading method, including:

[0089] Step S301b: Parse the above-injected data frame to obtain the refactored code;

[0090] Step S302b: Stop and delete the original application program in the satellite's operating system;

[0091] Step S303b: Transfer the refactored code to the operating system;

[0092] Step S304b: Use the refactored code as the latest application program and restart the latest application program, thereby overloading the above-injected data frame.

[0093] Exemplarily, for high-performance on-board products, relying on the LINUX operating system, the refactoring area can be created in the form of a folder, and the effective data can be created as a file in the folder, with the frame sequence number of the data frame as the file name and.dat as the file suffix. The method of overloading the above-injected data frame in this application helps to improve the performance of on-board products, enables them to execute tasks based on an updated application program, meets the high-performance operation requirements, and enhances the functions and processing capabilities of the satellite system.

[0094] Figure 2 It is a flowchart of the on-board data refactoring method according to another embodiment of this application, Figure 3 It is a flowchart of generating a refactored above-injected data frame in an embodiment of this application, Figure 4 It is a flowchart of verifying the above-injected data frame in an embodiment of this application, Figure 5 It is a flowchart of overloading the above-injected data frame in an embodiment of this application, Figure 6 It is a flowchart of overloading the above-injected data frame according to another embodiment of this application. The following will combine Figures 2 to 6 Two complete embodiments are used to introduce the on-board data refactoring method of this application respectively.

[0095] Embodiment 1

[0096] Embodiment 1 of this application will introduce the code refactoring method of the on-board computer of a certain model satellite, such asFigure 2 As shown in the figure, it includes:

[0097] Step Sp10, generating a reconstructed frame: According to the method for generating the upper injection file, referring to the upper injection data frame format, splitting and generating a reconstructed data frame of the binary bitstream based on the surveying and mapping software.

[0098] Step Sp20, upper injecting the reconstructed frame: Monitoring the telemetry of the reconstruction status, upper injecting the reconstructed data frame of the binary bitstream based on the ground measurement and control station, and completing the correctness and integrity verification of the upper injected data.

[0099] Step Sp30, loading the reconstructed data: Completing the reload operation of the reconstructed code according to the method for reloading the upper injected data.

[0100] In Embodiment 1, as Figure 3 shown in the figure, Step Sp10 includes:

[0101] Step Sp102, splitting the upper injected data: Splitting the binary bitstream data with a fixed length according to the preset requirements for the length of the upper injected data frame.

[0102] Step Sp103, encapsulating the upper injected data frame: Encapsulating the split binary bitstream data once according to the upper injected data frame format.

[0103] Step Sp104, encapsulating the reconstructed data frame: Encapsulating the once-encapsulated binary bitstream data a second time according to the transmission protocol of the preset satellite-ground forward link to generate a reconstructed frame of the binary bitstream.

[0104] In Embodiment 1, as Figure 4 shown in the figure, Step Sp20 includes:

[0105] Step Sp201, upper injecting the reconstructed data frame: Through the satellite-ground forward channel, sending the reconstructed frames of the binary bitstream except the last frame to the satellite in sequence; when the reconstructed frame passes the correctness verification of the upper injected data, the valid data of the reconstructed frame is transferred to the satellite product to be updated; otherwise, it is discarded.

[0106] Step Sp202, judging the frame number and performing data verification: The ground sends the last reconstructed frame to perform the integrity verification of the upper injected data; if the integrity verification of the data is passed, go to Step Sp203; otherwise, the frame loss situation can be judged through the telemetry of the reconstruction status sent from the satellite, and return to Step Sp201 for frame compensation operation.

[0107] Step Sp203, generating the complete reconstructed data: Performing a packet assembly operation on all the valid upper injected data to form the complete reconstructed data.

[0108] In Embodiment 1, as Figure 5 shown in the figure, Step Sp30 includes:

[0109] Step Sp301a, FLASH Erase and Write Operation: Automatically perform a reconstruction operation to erase the original code in the code area of the FLASH.

[0110] Step Sp302a, FLASH Write Operation: Transfer the overwritten code in the reconstruction area of the SRAM to the code area in the FLASH.

[0111] Step Sp303a, Computer Soft Reset: Perform a soft reset through ground commands to complete the overwritten code reload operation.

[0112] Embodiment Two

[0113] Embodiment Two of this application will introduce the code reconstruction method of a certain type of satellite mission planning module (such as a processing planner), as Figure 2 shown, including:

[0114] Step Sp10, Generate Reconstruction Frame: According to the overwritten file generation method, refer to the overwritten data frame format, and split and generate a binary bitstream reconstruction data frame based on the ground test software.

[0115] Step Sp20, Overwrite Reconstruction Frame: Monitor the reconstruction status telemetry, complete the overwriting of the binary bitstream reconstruction data frame based on the ground measurement and control station, and complete the correctness and integrity verification of the overwritten data.

[0116] Step Sp30, Load Reconstruction Data: Complete the reload operation of the reconstruction code according to the overwritten data reload method.

[0117] In Embodiment Two, as Figure 3 shown, Step Sp10 includes:

[0118] Step Sp101, Binary Data Generation: Modify the suffix file type of the satellite data file to be overwritten so that it is represented as binary bitstream data.

[0119] Step Sp102, Overwritten Data Split: Split the binary bitstream data into fixed lengths according to the preset overwritten data frame length requirement.

[0120] Step Sp103, Overwritten Data Frame Encapsulation: Perform a primary encapsulation on the split binary bitstream data according to the overwritten data frame format.

[0121] Step Sp104, Reconstruction Data Frame Encapsulation: Perform a secondary encapsulation on the binary bitstream data after the primary encapsulation according to the transmission protocol of the preset satellite-ground forward link to generate a binary bitstream reconstruction frame.

[0122] In Embodiment Two, as Figure 4 shown, Step Sp20 includes:

[0123] Step Sp201, Reconstruct the data frame and upload: Through the space-ground forward channel, the reconstructed frames of the binary bit stream except the last frame are sent to the satellite in sequence; when the reconstructed frame passes the correctness verification of the uploaded data, the valid data of the reconstructed frame is transferred to the satellite product to be updated; otherwise, it is discarded.

[0124] Step Sp202, Judge the frame sequence number and perform data verification: The ground sends the last reconstructed frame to perform the integrity verification of the uploaded data; if the integrity verification of the data is passed, go to Step Sp203; otherwise, the lost frame situation can be judged through the reconstructed status telemetry sent down by the satellite, and return to Step Sp201 for frame compensation operation.

[0125] Step Sp203, Generate complete reconstructed data: Perform packet assembly on all the valid uploaded data to form complete reconstructed data.

[0126] In Embodiment 2, as Figure 6 shown, Step Sp30 includes:

[0127] Step Sp301b, Stop the application APP: Manually stop the satellite application software to be updated through ground commands.

[0128] Step Sp302b, Start the reconstruction APP: Manually start the overloaded code through ground commands to complete the operations of deleting the original code, parsing and transporting the uploaded data; after completion, the reconstructed code returns the reconstruction completion telemetry to the ground.

[0129] Step Sp303b, Stop the reconstruction APP and start the application APP: Manually stop the overloaded code through ground commands and restart the satellite application software to complete the overloaded code upload operation.

[0130] The two embodiments mentioned above in this application (i.e., Embodiment 1 and Embodiment 2) are both practical examples of certain on-orbit satellites. The difference between them is that Embodiment 1 describes the CPU (Central Processing Unit) software of certain satellite products with high reliability requirements on the satellite. Embodiment 2 describes the CPU software of certain high-performance satellite products on the satellite. The reason is that there is a certain degree of difference between high reliability and high performance. High-reliability satellite products may not be able to adopt a powerful operating system such as LINUX due to their own performance reasons, so that the CPU software will directly interact with the hardware interface.

[0131] Regarding Embodiment 1, for on-orbit products with high reliability, the CPU software to be uploaded itself is an executable.out file, and there is no need to perform the operation of "converting to binary" on the code to be uploaded. Therefore, in step Sp10 of Embodiment 1, only the unpacking and encapsulation of the code to be uploaded need to be completed. In addition, the CPU software directly interacts with the FLASH and SRAM. It is initially stored in the FLASH. When running normally, the code needs to be transferred to the program area of the SRAM through the startup program. Therefore, the application code running during normal operation is the one on the SRAM. This ensures the security and rationality of the FLASH erasure during code operation in step Sp30.

[0132] Regarding Embodiment 2, for on-orbit products with high performance, the high-performance operating system takes over all the hardware interfaces of the on-orbit products, and the CPU software runs on the operating system as an APP on the operating system. The high-performance operating system separately undertakes the functions of the software platform and can run multiple application software simultaneously to achieve multiple functions. To improve the uploading efficiency, this application supports the simultaneous uploading of multiple application software, and the method adopted can be to package multiple software to be uploaded into a compressed package. Therefore, in step Sp10 of Embodiment 2, an operation of "converting to binary" needs to be performed in step Sp101, and at the same time, the uploaded data needs to be parsed in step Sp30, that is, the unpacking operation.

[0133] Combined with Figure 4 As shown, for step Sp20, the overall ideas of Embodiment 1 and Embodiment 2 are the same, but there can be differences in the details.

[0134] In Embodiment 1, a space is opened up on the SRAM as the reconstruction area, and there is only the concept of binary bit data. Therefore, the reconstruction module of the on-orbit product application code needs to declare the memory address of the reconstruction area to concretize the binary data into specific concepts such as an effective data array and a received data flag array in the form of a structure, which may be relatively complex in actual applications.

[0135] Embodiment 2 relies on the LINUX operating system, and the memory address has been packaged once. The reconstruction area can even be created in the form of a folder, and the effective data of the reconstructed data frame can be created as a file in the folder, and the frame sequence number of the data frame can be used as the file name with.dat as the file suffix.

[0136] Embodiment 2 can simplify the reconstruction process based on the high-performance operating system.

[0137] This application has the following beneficial effects:

[0138] (1) Low redundancy: By adding a minimal amount of data to the conventional space-ground transmission protocol in this application, the reliability of the reconstruction process can be ensured, improving the utilization rate of uplink data and the reconstruction efficiency.

[0139] (2) High availability: The telemetry of the reconstruction status designed in this application can intuitively judge the on-board data reconstruction situation throughout the entire cycle of the reconstruction process, ensuring the security of the reconstruction process and improving the reconstruction efficiency at the same time.

[0140] (3) Reliability: This application designs the verification of the correctness and integrity of the uploaded data, which can promptly detect the success or failure of the reconstruction process and ensure the security of the system.

[0141] (4) Flexibility: This application supports the function of resuming interrupted transfer in case of abnormal or occupied space-ground transmission channels, ensuring the flexibility of the reconstruction process and improving the reconstruction efficiency.

[0142] This application also includes an on-board data reconstruction system, which includes a memory and a processor. Among them, the memory is used to store instructions executable by the processor; the processor is used to execute the instructions to implement the on-board data reconstruction method described above.

[0143] Figure 7 is the system block diagram of the on-board data reconstruction system according to an embodiment of this application. Refer to Figure 7 As shown, the on-board data reconstruction system 700 may include an internal communication bus 701, a processor 702, a read-only memory (ROM) 703, a random access memory (RAM) 704, and a communication port 705. The on-board data reconstruction system 700 may also include a hard disk 706. The internal communication bus 701 can realize data communication between components of the on-board data reconstruction system 700. The processor 702 can make judgments and give prompts. In some embodiments, the processor 702 may be composed of one or more processors. The communication port 705 can realize data communication between the on-board data reconstruction system 700 and the outside. In some embodiments, the on-board data reconstruction system 700 can send and receive information and data from the network through the communication port 705. The on-board data reconstruction system 700 may also include different forms of program storage units and data storage units, such as a hard disk 706, a read-only memory (ROM) 703, and a random access memory (RAM) 704, which can store various data files used for computer processing and / or communication, as well as possible program instructions executed by the processor 702. The processor executes these instructions to implement the main part of the method. The results processed by the processor are transmitted to the user device through the communication port and displayed on the user interface.

[0144] The above-described on-board data reconstruction method can be implemented as a computer program, stored in the hard disk 706, and loaded into the processor 702 for execution to implement the on-board data reconstruction method of the present application.

[0145] The present application also includes a computer-readable medium storing computer program code, which implements the on-board data reconstruction method described above when executed by a processor.

[0146] When the on-board data reconstruction method is implemented as a computer program, it can also be stored in a computer-readable storage medium as an article of manufacture. For example, the computer-readable storage medium may include, but is not limited to, magnetic storage devices (e.g., hard disks, floppy disks, magnetic strips), optical disks (e.g., compact discs (CDs), digital versatile discs (DVDs)), smart cards, and flash memory devices (e.g., electrically erasable programmable read-only memories (EPROMs), cards, sticks, key drives). In addition, the various storage media described herein can represent one or more devices and / or other machine-readable media for storing information. The term "machine-readable medium" may include, but is not limited to, wireless channels and various other media (and / or storage media) that can store, contain, and / or carry code and / or instructions and / or data.

[0147] It should be understood that the embodiments described above are merely illustrative. The embodiments described herein can be implemented in hardware, software, firmware, middleware, microcode, or any combination thereof. For a hardware implementation, the processor can be implemented within one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), processors, controllers, microcontrollers, microprocessors, and / or other electronic units designed to perform the functions described herein, or a combination thereof.

[0148] Some aspects of the present application can be executed entirely by hardware, entirely by software (including firmware, resident software, microcode, etc.), or by a combination of hardware and software. The above-mentioned hardware or software can all be referred to as "data blocks", "modules", "engines", "units", "components" or "systems". The processor can be one or more application specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DAPDs), programmable logic devices (PLDs), field programmable gate arrays (FPGAs), processors, controllers, microcontrollers, microprocessors, or combinations thereof. In addition, aspects of the present application may be embodied as a computer product located in one or more computer-readable media, which includes computer-readable program code. For example, the computer-readable medium may include, but is not limited to, magnetic storage devices (such as hard disks, floppy disks, magnetic tapes...), optical discs (such as compact discs CD, digital versatile discs DVD...), smart cards, and flash memory devices (such as cards, sticks, key drives...).

[0149] The computer-readable medium may contain a propagated data signal having computer program code embodied therein, for example, on a baseband or as part of a carrier wave. The propagated signal may take many forms, including electromagnetic, optical, and the like, or suitable combinations thereof. The computer-readable medium can be any computer-readable medium other than a computer-readable storage medium, which can communicate, propagate, or transport a program for use by connecting to an instruction execution system, apparatus, or device. The program code located on the computer-readable medium can be propagated through any appropriate medium, including radio, cable, fiber optic cable, radio frequency signal, or similar media, or any combination of the above media.

[0150] The basic concepts have been described above. Obviously, for those skilled in the art, the above application disclosure is only an example and does not constitute a limitation to the present application. Although not explicitly stated here, those skilled in the art may make various modifications, improvements, and corrections to the present application. Such modifications, improvements, and corrections are proposed in the present application, so such modifications, improvements, and corrections still fall within the spirit and scope of the exemplary embodiments of the present application.

[0151] Meanwhile, the present application uses specific terms to describe the embodiments of the present application. Such as "one embodiment", "an embodiment", and / or "some embodiments" mean a certain feature, structure, or characteristic related to at least one embodiment of the present application. Therefore, it should be emphasized and noted that the "one embodiment" or "an embodiment" or "an alternative embodiment" mentioned twice or more at different positions in this specification does not necessarily refer to the same embodiment. In addition, certain features, structures, or characteristics in one or more embodiments of the present application can be appropriately combined.

[0152] In some embodiments, numbers are used to describe components and the quantity of attributes. It should be understood that such numbers used in the description of embodiments are, in some examples, modified by the modifiers "about", "approximately" or "substantially". Unless otherwise stated, "about", "approximately" or "substantially" indicate that the stated number allows a variation of ±20%. Accordingly, in some embodiments, the numerical parameters used in the specification and claims are approximate values, which may vary according to the characteristics required by individual embodiments. In some embodiments, the numerical parameters should consider the specified significant digits and adopt the method of retaining the general number of digits. Although the numerical ranges and parameters used in some embodiments of the present application to confirm the breadth of their scope are approximate values, in specific embodiments, such numerical settings are as precise as possible within the feasible range.

Claims

1. A method for on-orbit data reconstruction, characterized in that, including: The ground station generates a reconstructed upload data frame according to the upload file and the upload data frame format; The ground station uploads the upload data frame to the satellite; the satellite performs a correctness check on the upload data frame, performs an integrity check on the upload data frame, and telemeters the reconstruction status of the upload data frame to the ground station; In response to passing the correctness check and the integrity check, the satellite reloads the upload data frame according to a preset upload data reloading method.

2. The on-orbit data reconstruction method according to claim 1, characterized in that, The ground station generates a reconstructed upload data frame according to the upload file and the upload data frame format, including: Construct the upload file into binary bitstream data; Split the binary bitstream data according to a preset data frame length to obtain split data; Perform a first encapsulation on the split data according to the upload data frame format to obtain first encapsulated data; Perform a second encapsulation on the first encapsulated data according to a preset satellite-ground forward link transmission protocol to obtain second encapsulated data, and use the second encapsulated data as the upload data frame.

3. The on-orbit data reconstruction method according to claim 1, characterized in that The number of upload data frames is multiple; the ground station uploads the upload data frames to the satellite; the satellite performs a correctness check on the upload data frames, performs an integrity check on the upload data frames, and telemeters the reconstruction status of the upload data frames to the ground station, including: Step S201: The ground station sequentially uploads the remaining upload data frames except the last upload data frame to the satellite; the satellite performs a correctness check on the upload data frames, and saves the upload data frames that pass the correctness check and discards the upload data frames that do not pass the correctness check; Step S202: The ground station uploads the last upload data frame to the satellite; the satellite performs an integrity check on the upload data frame. In response to passing the integrity check, it proceeds to execute Step S203; or, in response to not passing the integrity check, the ground station judges the frame loss situation according to the reconstruction status telemetry and performs a frame filling operation, and proceeds to execute Step S201; Step S203: The satellite performs a packet assembly operation on the saved upload data frames to generate a complete reconstructed data frame, and uses the complete reconstructed data frame as the reloaded upload data frame.

4. The on-orbit data reconstruction method according to any one of claims 1-3, characterized in that The satellite reloads the upload data frame according to a preset upload data reloading method, including: Parse the upload data frame to obtain a reconstruction code; Erase the original code in the code area of the satellite's FLASH; Write the reconstruction code into the code area of the FLASH; According to the computer soft reset instruction of the ground station, transfer the reconstruction code in the FLASH to the satellite's SRAM, thereby reloading the upload data frame.

5. The on-orbit data reconstruction method according to any one of claims 1-3, characterized in that The satellite reloads the upload data frame according to a preset upload data reloading method, including: Parse the upload data frame to obtain a reconstruction code; Stop and delete the original application program in the satellite's operating system; Transfer the reconstruction code to the operating system; Use the reconstruction code as the latest application program, and restart the latest application program, thereby reloading the upload data frame.

6. The on-board data reconstruction method according to claim 1 or 3, wherein The satellite performs a correctness check on the uplink data frame, including: Adopting the satellite-ground communication data protocol to obtain the starting position of the uplink data frame according to the synchronization header; Obtaining the termination position of the uplink data frame according to the data length; Judging whether the uplink data frame is valid according to the check field.

7. The on-orbit data reconstruction method according to claim 1 or 3, characterized in that, The number of uplink data frames is multiple; performing an integrity check on the uplink data frames, including: Sequentially splicing the frame numbers of the uplink data frames to obtain a spliced frame number; If the frame number of the last uplink data frame is equal to the number of uplink data frames, the integrity check is passed; or If the frame number of the last uplink data frame is not equal to the number of uplink data frames, the integrity check fails; obtaining the frame numbers of the lost data frames according to the spliced frame number, and sending the frame numbers of the lost data frames to the ground station through the reconstruction status telemetry.

8. The on-board data reconstruction method according to claim 1, wherein In the format of the uplink data frame: The first byte is the frame type, and the frame type includes the first reconstruction data, intermediate reconstruction data, and last reconstruction data; The second byte is the frame number.

9. The on-orbit data reconstruction method according to claim 1, characterized in that The data structure of the reconstruction status telemetry includes: the current uplink status, uplink frame transceiver status, frame loss situation, and received frame display; among them, The current uplink status includes any one of uplink start, uplink in progress, uplink end, and uplink completed; The uplink frame transceiver status includes: the frame number of the latest uplink data frame received by the satellite and the number of uplink data frames; The frame loss situation includes: the frame numbers of the lost data frames recorded by the satellite; The received frame display includes: the first bit flag and the second bit flag; in the initial state, the satellite has the first bit flag; when the satellite receives the uplink data frame, the first bit flag is set to the second bit flag.

10. The on-orbit data reconstruction method according to claim 2, wherein The data structure of the second encapsulated data includes: A frame header for synchronizing the frame header position; A frame main header and a frame secondary header for jointly determining the uplink data channel and the data destination; The instruction execution time for judging the execution time of the instruction; An instruction code for distinguishing different instructions of the same on-board single machine; Valid data for recording data; A sum check for judging whether the data frame is correct.

11. A on-board data reconstruction system, characterized in that Includes: A memory for storing instructions executable by a processor; A processor for executing the instructions to implement the on-board data reconstruction method according to any one of claims 1-10.

12. A computer-readable medium storing computer program code, characterized in that, The computer program code implements the on-board data reconstruction method according to any one of claims 1-10 when executed by a processor.

Images