A method for on-orbit maintenance of spaceborne software

Abstract

A kind of on-orbit maintenance method of spaceborne software, establish software on-orbit injection three-level index management model, three-level index corresponds to three levels of model form respectively: the uppermost layer is on-orbit injection unified management model, middle layer is injection function module data structure model, the lowermost layer is injection instruction data structure model.This method effectively solves the problem that existing spaceborne software SRAM program injection mode lacks monitoring and specification, provides good on-orbit injection program record, recovery and injection program write-back EERPOM etc. Operation, makes on-orbit maintenance operation more automated, simplifies on-orbit maintenance process, improves on-orbit maintenance capability of spaceborne software;Reduce the complexity of on-orbit maintenance operation of ground personnel, reduce the risk of accident caused by personnel operation error.

Description

Technical Field

[0001] This invention belongs to the field of on-orbit maintenance technology for spaceborne software, and relates to a method for on-orbit maintenance of spaceborne software. Background Technology

[0002] The hook function-based software on-orbit maintenance method has been applied in many models with good results, but it has the following limitations: First, the number of on-orbit maintenance operations that can be used simultaneously is limited. Because the number of on-orbit maintenance interfaces reserved in the system software is relatively small, usually 8 or 16, it does not support more on-orbit maintenance operations than the number of reserved interfaces to exist simultaneously (they can only provide interfaces for new operation requirements by replacing the on-orbit maintenance operations that are not currently in use); Second, the number of pre-embedded hook functions is limited. Because the more pre-embedded hook functions in the application software, the more time is occupied in the task, the more pre-embedded hook functions should not be too many, but this will affect the convenience of on-orbit modification of the software.

[0003] The current satellite attitude and orbit control subsystem control computer uses an EEPROM+SRAM memory structure. The program is loaded from the EEPROM into the SRAM, with the text, data, and bss segments all residing in the SRAM. All contents of the SRAM area are modifiable. If on-orbit maintenance is required, SRAM program injection is used, allowing direct modification of the program code in the text segment of the SRAM, offering greater flexibility compared to the hook function method. If it is desired that the injected program is not lost after a power outage, the on-orbit injected program portion in the SRAM is written back to the EEPROM. Upon power-on, the program in the EEPROM is moved to the SRAM, resulting in the latest injected software state. Due to the flexibility of SRAM program injection, several GNC application software models, such as KXX and XX12, have eliminated the hook function on-orbit maintenance method, instead achieving on-orbit maintenance by directly modifying the text segment in the SRAM.

[0004] In comparison, SRAM program injection offers significantly greater flexibility than hook function-based injection, but it faces several challenges: First, eliminating hook functions in on-orbit maintenance leaves the onboard software without automatic recording and management of its on-orbit maintenance status. Relying on manual recording by ground operators can lead to multiple on-orbit software injection needs over a long spacecraft lifespan, with uncertain timing and significant time spans, potentially causing confusion in on-orbit maintenance management. Second, there's a lack of convenient mechanisms to restore the onboard software to its state before on-orbit injection modifications. Typically, restoring the software to its original state after on-orbit injection requires re-injecting a series of original instruction codes. Third, there's a lack of convenient operations for writing on-orbit injected instructions / data back from SRAM to EEPROM. Writing the injected modifications from SRAM to EEPROM requires a series of EEPROM injection operations on the ground, a cumbersome process prone to errors. Summary of the Invention

[0005] The technical problem solved by this invention is to provide an on-orbit maintenance method for spaceborne software, effectively addressing the lack of monitoring and standardization in existing on-orbit SRAM program injection methods. It provides robust on-orbit program recording, recovery, and EERPOM write-back operations. This automates on-orbit maintenance operations, simplifies the on-orbit maintenance process, improves the on-orbit maintenance capability of spaceborne software, reduces the complexity of on-orbit maintenance operations for ground personnel, and lowers the risk of accidents caused by human error.

[0006] The technical solution of this invention is: an on-orbit maintenance method for spaceborne software, wherein the executable code of the spaceborne software is stored in EEPROM, and after power-on, the executable code of the spaceborne software is read from EEPROM into SRAM, and execution of the executable code in SRAM begins; the on-orbit maintenance method includes the step of modifying the off-address program of function module A called in the spaceborne software.

[0007] S101. The starting address, byte length Q, and compiled program code of the replacement program block InjectBlock_A used to replace function module A in SRAM are injected into the onboard software. The onboard software addresses according to the starting address of the replacement program block InjectBlock_A in SRAM and stores the compiled program code of the replacement program block InjectBlock_A into the corresponding Q consecutive memory spaces in SRAM.

[0008] S102. The address of the "instruction code for calling function module A" in SRAM and the "instruction code for calling replacement program block InjectBlock_A" are recorded in the onboard software. The onboard software replaces the "instruction code for calling function module A" stored in SRAM with the "instruction code for calling replacement program block InjectBlock_A", thereby updating the onboard software execution code. The "instruction code for calling replacement program block InjectBlock_A" performs the operation of "jumping to replacement program block InjectBlock_A".

[0009] S103. The updated onboard software will be executed after the ground equipment uploads the enable command and enables the on-orbit maintenance operation of function module A.

[0010] Furthermore, the content recorded on the onboard software in S102 also includes the mapping address of the "instruction code for calling function module A" in the EEPROM and the "instruction code for calling function module A"; the "instruction code for calling function module A" is used to perform the operation of "jumping to the program block of function module A".

[0011] Furthermore, it also includes the step of writing the updated onboard software executable code into the EEPROM:

[0012] S201. The ground equipment writes the EEPROM write-back instruction to the spaceborne software. After the spaceborne software automatically finds the EEPROM write-back instruction, it reads the recorded "instruction code for calling function module A" in the EEPROM mapping address and "instruction code for calling replacement program block InjectBlock_A". The spaceborne software performs addressing and writes the "instruction code for calling replacement program block InjectBlock_A" into the "instruction code for calling function module A" in the EEPROM mapping address.

[0013] S202. The ground equipment uploads the mapping address, byte length Q, and compiled program code of the replacement program block InjectBlock_A in the EEPROM. After receiving the data, the onboard software addresses the memory according to the mapping address of the replacement program block InjectBlock_A in the EEPROM and writes the compiled program code of the replacement program block InjectBlock_A into the corresponding Q consecutive memory spaces in the EEPROM.

[0014] Furthermore, it also includes the step of ground equipment executing the recovery function module A to the original software state:

[0015] S301. The ground equipment uploads the recovery command. After the onboard software automatically finds the recovery command, it reads the recorded "instruction code for calling function module A" and the address of "instruction code for calling function module A" in the SRAM. After addressing, it writes the "instruction code for calling function module A" into the address in the SRAM.

[0016] Furthermore, this includes the in-place program modification steps for function module A called in the onboard software:

[0017] S101. The number of instructions to be modified in function module A, the address of each instruction to be modified in SRAM, and the modified instruction code are written into the onboard software and recorded. The onboard software addresses according to the address of each instruction to be modified in SRAM and writes the corresponding modified instruction code into the address of the SRAM being addressed, until all instructions to be modified are replaced, thereby updating the execution code of the onboard software.

[0018] S102. The updated onboard software will be executed after the ground equipment uploads the enable command and enables the on-orbit maintenance operation of function module A.

[0019] Furthermore, the content recorded in the onboard software in S101 also includes: the mapping address of each instruction to be modified in function module A in the EEPROM, and each instruction code to be restored; the content of the instruction code to be restored is consistent with the content of the instruction code before modification.

[0020] Furthermore, it also includes the step of writing the updated onboard software execution code into the EEPROM:

[0021] S201. The ground equipment writes the EEPROM back instruction to the spaceborne software. After the spaceborne software automatically finds the EEPROM back instruction, it reads the mapping address of each instruction to be modified in the EEPROM of the recorded function module A and the modified instruction code of each instruction. It then addresses the EEPROM according to the mapping address of each instruction to be modified in the function module A and writes the corresponding modified instruction code into the mapping address of the EEPROM being addressed, until all instructions to be modified are entered.

[0022] Furthermore, it also includes the step of ground equipment executing the recovery function module A to the original software state:

[0023] S301. The ground equipment uploads the recovery command. After the onboard software automatically finds the recovery command, it reads the recorded "address of each instruction to be modified in function module A in SRAM" and each instruction to be recovered. It then addresses the instruction according to the "address of each instruction to be modified in function module A in SRAM" and writes the corresponding instruction to be recovered into the address of the SRAM being addressed. This process continues until all modified instruction codes are recovered.

[0024] Furthermore, a three-level index data structure is established to store the records of on-orbit maintenance operations; the three-level index data structure includes "on-orbit maintenance unified management data structure", "function module on-orbit maintenance record data structure", and "instruction code modification record data structure".

[0025] Among them, the "Unified Management Data Structure for On-Orbit Maintenance" includes the set of each on-orbit maintenance function module recorded in the "On-Orbit Maintenance Record Data Structure for Function Modules";

[0026] The "Function Module On-Orbit Maintenance Record Data Structure" is used to record the on-orbit maintenance data of a single function module, including the status flag of the on-orbit maintenance instructions, the number of instructions to be modified, and the set of instructions injected for modification on the orbit; wherein, the set of instructions injected for modification on the orbit is the set of instructions of function module A currently undergoing on-orbit maintenance, recorded in the "Instruction Code Modification Record Data Structure";

[0027] When the off-address program is modified, the "Instruction Code Modification Record Data Structure" is used to record the single instruction code data when function module A is maintained on-orbit, including the address of the "Instruction Code for Calling Function Module A" in SRAM, the mapping address of the "Instruction Code for Calling Function Module A" in EEPROM, the "Instruction Code for Calling Function Module A", and the "Instruction Code for Calling Replacement Program Block InjectBlock_A".

[0028] When the original program is modified, the "Instruction Code Modification Record Data Structure" is used to record the single instruction code data when function module A is maintained on orbit, including the "address of the instruction to be modified in SRAM", the "mapping address of the instruction to be modified in EEPROM", the "instruction code before modification", and the "instruction code after modification".

[0029] The advantages of this invention compared to the prior art are:

[0030] (1) The on-orbit maintenance method for spaceborne software proposed in this invention has the function of recording all information injected into the on-orbit maintenance program. On the one hand, it is convenient to view the historical on-orbit maintenance status; on the other hand, it supports the function of one-click rewriting of the SRAM area injected program back to the EEPROM area; and on the other hand, it supports the function of one-click recovery of on-orbit maintenance operations.

[0031] (2) This invention proposes a method of “three-level index + data structure + general function interface for data structure operation”, which does not require operating system software support, enabling the on-board software to have on-orbit maintenance and management functions, and making it more flexible and easy to use. Attached Figure Description

[0032] Figure 1 This is a flowchart of the present invention;

[0033] Figure 2 This is a schematic diagram of an on-orbit injection management model for spaceborne software based on a three-level index. Detailed Implementation

[0034] To better understand the above technical solutions, the technical solutions of this application will be described in detail below with reference to the accompanying drawings and specific embodiments. It should be understood that the embodiments of this application and the specific features in the embodiments are detailed descriptions of the technical solutions of this application, rather than limitations on the technical solutions of this application. In the absence of conflict, the embodiments of this application and the technical features in the embodiments can be combined with each other.

[0035] The following description, in conjunction with the accompanying drawings, provides a more detailed explanation of an on-orbit maintenance method for spaceborne software based on a three-level index, as provided in the embodiments of this application.

[0036] In the solutions provided in the embodiments of this application, such as Figure 1 As shown, an on-orbit maintenance method for spaceborne software based on a three-level index is implemented as follows (in this embodiment, the method design and implementation are both based on ANSI-C language):

[0037] Preliminary design work is carried out before the onboard software runs, including:

[0038] 101. Establish a three-level index management model for software injection in orbit, corresponding to three levels of the model: the top level is the unified management model for in-orbit maintenance, the middle level is the in-orbit maintenance record model for function modules, and the bottom level is the instruction code modification record model.

[0039] See the model diagram. Figure 2 When establishing a three-level index management model, it specifically includes: the top-level unified management model for on-orbit maintenance, which records the set of on-orbit maintenance operations for all specified function modules; the middle-level on-orbit maintenance record model for function modules, which records the on-orbit maintenance operations for specified function modules, and nested within the top-level unified management model for on-orbit maintenance; and the bottom-level instruction code modification record model, which records the modification operations for specified instruction codes, and nested within the middle-level on-orbit maintenance record model for function modules.

[0040] 102. In accordance with the design of the three-level index management model, design the "three-level index data structure" and "general operation function interface" in the onboard software, and determine the "design constraints and usage constraints" for the "three-level index data structure". The "three-level index data structure" corresponds to the three-level index management model in step 101 and defines the "on-orbit maintenance unified management data structure StructMaintainManage", "function module on-orbit maintenance record data structure StructMaintainFunc", and "instruction code modification record data structure StructInstruction".

[0041] The design of the "three-level index data structure", "general operation function interface" and "design constraints and usage constraints" are shown in Tables 1, 2 and 3 below, respectively.

[0042] Table 1 shows that "StructMaintainManage" specifically includes "the number of cached injection function modules in the on-orbit injection data table", "the set of on-orbit injection function modules", and "the set of function pointers for the general operation function interface". Its function is to uniformly manage the on-orbit maintenance status of the spaceborne software. Specifically, it includes: according to ground command requirements, performing on-orbit maintenance operations on any specified function module by calling the function pointers in "StructMaintainManage"; "the set of on-orbit injection function modules" is the record data set of all function modules that have undergone on-orbit maintenance operations. Before on-orbit maintenance, "the set of on-orbit injection function modules" is empty. After on-orbit maintenance, "the set of on-orbit injection function modules" is the data set of each on-orbit maintenance function module recorded by StructMaintainFunc.

[0043] StructMaintainFunc specifically includes the "function module start address (as ID identifier)," the "on-orbit injection operation module enable switch," the "on-orbit injection execution status flag," the "number of on-orbit injection modification instructions," and the "on-orbit injection modification instruction set." Its function is to record the on-orbit maintenance data of a single function module. Before on-orbit maintenance occurs, the "on-orbit injection modification instruction set" is empty; after on-orbit maintenance, the "on-orbit injection modification instruction set" is the set of instruction code data for the current function module's on-orbit maintenance operation recorded by StructInstruction.

[0044] StructInstruction specifically includes "the address of the instruction to be modified in the SRAM program execution area (NULL indicates no operation)", "the address of the instruction to be modified in the EEPROM program storage area (NULL indicates no operation)", "the original instruction code", and "the newly injected instruction code". Its function is to record single instruction code data during on-orbit maintenance operations.

[0045] This invention only requires defining variables for the unified on-orbit maintenance management data structure `StructMaintainManage`. The data structures `StructMaintainFunc` and `StructInstruction` are already nested within the current structure; for example:

[0046] StructMaintainManage structMaintainManage;

[0047] Table 2 shows that the "General Operation Function Interface" specifically includes 11 interface functions: "Update all recorded function modules to the newly injected state", "Restore all recorded function modules to the original software state", "Clear all on-orbit injection caches", "Write back all on-orbit injection states to EEPROM", "Inject on-orbit maintenance function (inject only, do not execute)", "Disable on-orbit maintenance function of a certain function", "Enable on-orbit maintenance function of a certain function", "Update a certain function module to the newly injected state", "Restore a certain function module to the original software state", "Write back the on-orbit injection state of a certain function module to EEPROM", and "Clear the on-orbit injection cache of a certain function module". The function is to provide all functional support for on-orbit maintenance operations.

[0048] Table 3 shows that "Design Constraints and Usage Constraints" specifically include "Macro Definition of the Size of the On-Orbit Injection Function Module Set", "Macro Definition of the Size of the On-Orbit Injection Modification Instruction Set", "Macro Definition of the Invalid Address of Instruction", and "Macro Definition of On-Orbit Maintenance Operation Status". The function is to limit the size of the data table of the on-orbit injection function module set through macro definitions, and to use them as a limiting condition for the access range of the data table.

[0049] Upon receiving a remote control frame, it is necessary to record and execute on-orbit maintenance information for function modules and instruction codes. All operations are implemented by calling interface function pointers in the StructMaintainManage structure, as shown in the following example:

[0050] structMaintainManage.pUpdateAllFunc();

[0051] Table 1. Definition of the three-level index data structure

[0052]

[0053] Table 2 General Operation Function Interface Definition

[0054]

[0055] Table 3 Definitions of Design Constraints and Usage Constraints

[0056]

[0057] 103. Design three remote control frame formats that match the "three-level index data structure", "general operation function interface" and "design constraints and usage constraints" in step 102: "program block injection remote control frame", "instruction code modification remote control frame" and "on-orbit maintenance operation remote control frame".

[0058] The program block injection remote control frame format is defined as shown in Table 4. It is mainly used to inject binary program instruction code of a specified length into a specified address in the SRAM program execution area.

[0059] Table 4 shows the frame format of the "Program Block Injection Remote Control Frame": 1-4 bytes: the starting injection address of the injected program block used to replace the original function, which is selected from the reserved memory in the SRAM program execution area; 5-8 bytes: the byte length of the injected program; 9-(8+4*N): the compiled program content. The length of the program content is variable and can contain program content modified by multiple function modules, but the maximum length cannot exceed the maximum number of bytes required by the system.

[0060] Table 4. Definition of Remote Control Frame Format for Program Block Injection

[0061]

[0062] The instruction code modification remote control frame format is defined as shown in Table 5. It is mainly used to notify the onboard software of the set of instruction codes for a specified function module to be modified. The frame format of the instruction code modification remote control frame includes: Bytes 1-4: the starting address of the parent function of the function module to be called, serving as the identifier of the function module to be maintained in orbit; Bytes 5-8: the number of on-orbit injection instructions, indicating the number of instructions to be modified; the following bytes sequentially store the first modification instruction of the function module, ..., the Mth modification instruction; 1≤M≤5. Each modification instruction contains the address of the instruction to be modified in the SRAM program execution area, the mapping address of the instruction to be modified in the EEPROM program storage area, the original instruction code, and the newly injected instruction code.

[0063] Table 5. Definition of Command Code Modification for Remote Control Frame Format

[0064]

[0065]

[0066] The on-orbit maintenance operation remote control frame format is defined as shown in Table 6, and is used for implementing on-orbit maintenance operations. The frame format for on-orbit maintenance operation remote control includes: the first byte: the range of on-orbit injection action; the second byte: the on-orbit injection usage status flag; the third byte: the on-orbit injection execution status flag; the fourth byte: whether to write back to EEPROM flag; and the following bytes can store the starting address of the function module.

[0067] The scope of on-orbit injection actions includes actions of a single function module and actions of all modules in a set of function modules. When the scope of on-orbit injection actions is the action of a single function module, the starting address of the function module needs to be filled in.

[0068] The on-orbit injection usage status flags include disabling on-orbit maintenance of modules specified in the on-orbit injection action range, enabling on-orbit maintenance of modules specified in the on-orbit injection action range, and clearing the cache of modules specified in the on-orbit injection action range.

[0069] The on-orbit injection execution status flags include no action, original program status, and newly injected program;

[0070] The EEPROM write-back flag includes no action, no EEPROM write-back, and EEPROM write-back.

[0071] According to the definition in "Design Constraints and Usage Constraints", each byte is assigned a corresponding status flag in different on-orbit maintenance tasks.

[0072] Table 6 Definition of Remote Control Frame Format for On-orbit Maintenance Operations

[0073]

[0074]

[0075] 104. In the onboard software implementation stage, the design in steps 101 to 103 is implemented by coding. The coding implementation involves data structure definition, variable definition, configuration macro parameter definition, general operation function, and remote control frame parsing function; the preliminary preparations for on-orbit maintenance operations are completed.

[0076] Example 1

[0077] During the on-orbit phase of onboard software, if on-orbit maintenance is required, including in the following situations:

[0078] Assuming that on-orbit maintenance modifications are performed on function module A, there are two options: off-site program modification and on-site program modification. When the number of modified instructions for function module A exceeds a preset threshold (5 in this embodiment), off-site program modification is initiated, including the following steps:

[0079] 201. The binary injection block InjectBlock_A, used to replace the function module A, is framed according to the "program block injection remote control frame," including: the starting injection address of InjectBlock_A, the byte length Q of the injected program, and the compiled program code of InjectBlock_A. It is injected into the onboard software via the remote control uplink channel for remote control frame parsing. After parsing, the "on-orbit maintenance function injection (injection only, no execution)" interface function is called. The execution content is as follows: Addressing is performed according to the starting injection address of InjectBlock_A, and the compiled program code of InjectBlock_A is stored in the corresponding Q consecutive memory spaces in the SRAM program execution area.

[0080] 202. Change the instruction calling function module A in the SRAM program execution area to call InjectBlock_A. Frame the instruction according to the "Instruction Code Modification Remote Control Frame," including: the starting address of the parent function of function module A, the number of on-orbit injection instructions, the address of the instruction code of function module A in the SRAM program execution area, the mapping address of the instruction code of function module A in the EEPROM program storage area, the original instruction code of function module A, and the newly injected instruction code of InjectBlock_A. Send this to the onboard software via the remote control uplink channel for remote control frame parsing. After parsing, call the "On-orbit Maintenance Function Injection (Injection Only, No Execution)" interface function. The execution content is as follows: The onboard software replaces the original instruction code of function module A stored in SRAM with the newly injected instruction code of InjectBlock_A, thereby updating the onboard software execution code. Specifically, the original instruction code of function module A is used to execute the operation of "jumping to the program block of function module A," and the newly injected instruction code of InjectBlock_A executes the operation of "jumping to the replacement program block InjectBlock_A." The data content above is then recorded into two data structures, StructMaintainFunc and StructInstruction, according to the variable definitions. Specifically, this includes:

[0081] The “StructMaintainFunc” records the “starting address of the parent function of the calling function module A”, the “on-orbit injection execution status flag” as 0xAA, the “on-orbit injection usage status flag” as 0x55, and the number of instructions to be modified as 1.

[0082] The “StructInstruction” records the “address of the instruction code that calls function module A in the SRAM program execution area”, the “mapped address of the instruction code that calls function module A in the EEPROM program storage area”, the “original instruction code that calls function module A”, and the “newly injected instruction code that calls InjectBlock_A”.

[0083] 301. Enable the on-orbit maintenance function modification operation of function module A, specifically including: framing the on-orbit maintenance enable operation of function module A according to the "on-orbit maintenance operation remote control frame", and sending it to the onboard software for remote control frame parsing through the remote control uplink channel. The onboard software automatically queries the on-orbit injection usage status flag. After finding the status flag as 0xAA, it calls the "Enable on-orbit maintenance function of a certain function" interface function, and executes the following: Enable the on-orbit maintenance function modification operation of function module A; and record the enabled on-orbit injection usage status flag into the StructMaintainFunc data structure.

[0084] According to the definition in Table 6, the framing result in this step can be as shown in Table 7.

[0085] Table 7 Enable Operation Framed Results

[0086]

[0087]

[0088] After implementing on-orbit maintenance modifications to function module A, the onboard computer runs the new onboard software and executes the InjectBlock_A program. If modifications to the SRAM area need to be written to the EEPROM area, the following steps are performed:

[0089] 401. The operation of writing the on-orbit injection program of function module A into the EEPROM area is framed according to the "on-orbit maintenance operation remote control frame" and sent to the onboard software for remote control frame parsing through the remote control uplink channel. The onboard software automatically checks whether the EEPROM write-back flag is needed. After finding that the status flag is 0xAA, it calls the interface function "write back the on-orbit injection status of a certain function module to EEPROM". The execution content is as follows: read the "mapping address of the instruction code of calling function module A in the EEPROM program storage area" and "new injection instruction code of calling InjectBlock_A" recorded in the data structure, perform address access, and write the "new injection instruction code of calling InjectBlock_A" into the mapping address of the EEPROM program storage area.

[0090] Simultaneously, the ground equipment sends the "mapping address of InjectBlock_A in EEPROM", the byte length Q of the injected program, and the compiled program code of InjectBlock_A to the onboard software. Upon receiving this information, the onboard software addresses the memory according to the "mapping address of InjectBlock_A in EEPROM" and writes the compiled program code of InjectBlock_A into the corresponding Q consecutive memory spaces in the EEPROM program storage area, completing the write operation to the EEPROM area. The write-back flag is then recorded in the StructMaintainFunc data structure. After the onboard software is powered on again, it reads the executable code from the EEPROM program storage area into the SRAM program execution area.

[0091] According to the definition in Table 6, the framing result in this step can be as shown in Table 8.

[0092] Table 8. Frame assembly results of the on-orbit injection program writing to the EEPROM area.

[0093]

[0094]

[0095] After implementing on-orbit maintenance and modifications to function module A, the onboard computer runs the new onboard software and executes the InjectBlock_A program. To restore function module A to its original software state, perform the following steps:

[0096] 401. The operation to restore function module A to its original software state is framed according to the "On-orbit Maintenance Operation Remote Control Frame" and sent to the onboard software for remote control frame parsing via the remote control uplink channel. The onboard software automatically queries the on-orbit injection execution status flag. After finding the status flag as 0x55, it calls the "Restore a function module to its original software state" interface function. The execution content is as follows: read the "address of the instruction code calling function module A in the SRAM program execution area" and the "original instruction code of calling function module A" recorded in the data structure, access the address, write the "original instruction code of calling function module A" into the "address of the instruction code of calling function module A in the SRAM program execution area", and complete the software original state restoration operation; and record the original program status flag into the StructMaintainFunc data structure.

[0097] According to the definition in Table 6, the framing result in this step can be as shown in Table 9.

[0098] Table 9. Framed results of function module A restoring to its original software state.

[0099]

[0100] The on-orbit maintenance status deregistration operation for function module A includes the following steps:

[0101] 501. The on-orbit maintenance status cancellation operation of function module A is framed according to the "on-orbit maintenance operation remote control frame" and sent to the onboard software for remote control frame parsing through the remote control uplink channel. The onboard software automatically queries the on-orbit injection usage status flag. After finding that the status flag is 0xFF, it calls the "clear on-orbit injection cache of a certain function module" interface function, which executes the following: deletes the record about the on-orbit maintenance operation of function module A in the data structure, realizes the cancellation of the on-orbit maintenance status of function module A; the on-orbit maintenance operation ends.

[0102] According to the definition in Table 6, the framing result in this step can be as shown in Table 10.

[0103] Table 10 Framed results of on-orbit maintenance status deregistration operation for function module A

[0104]

[0105] Example 2

[0106] During the on-orbit phase of onboard software, if on-orbit maintenance is required, including in the following situations:

[0107] Assuming on-orbit maintenance modifications are performed on function module A, when the number of modified instructions for function module A is less than a preset threshold (5 in this embodiment), in-place program modification is initiated. In-place program modification is primarily used for partial functional modifications of the function module, overwriting instruction codes in the original memory location of the function module. This includes the following steps:

[0108] 201. Frame the modification instruction codes of function module A in the SRAM program execution area according to the "instruction code modification remote control frame," including: the starting address of function module A, the number of instructions to be modified, the address of each instruction to be modified in the SRAM program execution area, the mapping address of each instruction to be modified in the EEPROM program storage area, each instruction to be modified, and the modified instruction code. Send this frame to the onboard software via the remote control uplink channel for remote control frame parsing. After parsing, call the "On-orbit maintenance function injection (injection only, no execution)" interface function. The execution content is as follows: The onboard software addresses each instruction to be modified according to its address in the SRAM program execution area and writes the corresponding modified instruction code into the address of the SRAM being addressed, until all instructions to be modified are replaced, thereby updating the onboard software execution code. Each instruction to be modified is the original execution code of function module A, and each modified instruction code is the updated execution code of function module A. Record the above-mentioned data content into the StructMaintainFunc and StructInstruction data structures according to the variable definitions, specifically including:

[0109] The “StructMaintainFunc” records the “starting address of function module A”, the “on-orbit injection execution status flag” as 0xAA, the “on-orbit injection usage status flag” as 0x55, and the number of instructions to be modified.

[0110] The “StructInstruction” records “the address of each instruction to be modified in the SRAM program execution area”, “the mapping address of each instruction to be modified in the EEPROM program storage area”, “each instruction to be modified”, and “each modified instruction code”.

[0111] 301. Enable the on-orbit maintenance function modification operation of function module A, specifically including: framing the on-orbit maintenance enable operation of function module A according to the "on-orbit maintenance operation remote control frame", and sending it to the onboard software for remote control frame parsing through the remote control uplink channel. The onboard software automatically queries the on-orbit injection usage status flag. After finding the status flag as 0xAA, it calls the "Enable on-orbit maintenance function of a certain function" interface function, and executes the following: Enable the on-orbit maintenance function modification operation of function module A; and record the enabled on-orbit injection usage status flag into the StructMaintainFunc data structure.

[0112] According to the definition in Table 6, the frame assembly result in this step can be as shown in Table 11.

[0113] Table 11 Enable Operation Framed Results

[0114]

[0115] After implementing on-orbit maintenance modifications to function module A, the onboard computer runs the new onboard software and executes the InjectBlock_A program. If modifications to the SRAM area need to be written to the EEPROM area, the following steps are performed:

[0116] 401. The operation of writing the on-orbit injection program of function module A into the EEPROM area is framed according to the "on-orbit maintenance operation remote control frame" and sent to the onboard software for remote control frame parsing through the remote control uplink channel. The onboard software automatically checks whether the EEPROM write-back flag is needed. After finding that the status flag is 0xAA, it calls the "write-back EEPROM of on-orbit injection status of a certain function module" interface function, which performs the following: reads the "mapping address of each instruction to be modified in the EEPROM program storage area" and "each modified instruction code" recorded in the data structure, addresses each instruction to be modified in function module A in the EEPROM according to its mapping address, and writes the corresponding modified instruction code into the mapping address of the EEPROM being addressed, until all instructions to be modified are entered, completing the write operation of the EEPROM area; and records the write-back EEPROM flag in the StructMaintainFunc data structure. After the onboard software is powered on again, it reads the execution code of the EEPROM program storage area into the SRAM program execution area.

[0117] According to the definitions in Table 6, the framing result in this step can be as shown in Table 12.

[0118] Table 12 Framed results of on-orbit injection program writing to EEPROM area

[0119]

[0120] After implementing on-orbit maintenance and modifications to function module A, the onboard computer runs the new onboard software and executes the InjectBlock_A program. To restore function module A to its original software state, perform the following steps:

[0121] 401. The operation to restore function module A to its original software state is performed by framing the "on-orbit maintenance operation remote control frame" and sending it to the onboard software for remote control frame parsing via the remote control uplink channel. The onboard software automatically queries the on-orbit injection execution status flag. After finding the status flag as 0x55, it calls the "Restore a function module to its original software state" interface function, which performs the following operations: reads the "address of each instruction to be modified in the SRAM program execution area" and "each instruction to be modified" recorded in the data structure, performs addressing according to the "address of each instruction to be modified in the SRAM program execution area" of function module A, and writes the corresponding instruction to be modified into the address of the SRAM being addressed; until all modified instruction codes are restored, the original software state restoration operation is completed; and the original program status flag is recorded in the StructMaintainFunc data structure.

[0122] According to the definition in Table 6, the frame assembly result in this step can be as shown in Table 13.

[0123] Table 13 Framed results of function module A restoring to its original software state

[0124]

[0125] The on-orbit maintenance status deregistration operation for function module A includes the following steps:

[0126] 501. The on-orbit maintenance status cancellation operation of function module A is framed according to the "on-orbit maintenance operation remote control frame" and sent to the onboard software for remote control frame parsing through the remote control uplink channel. The onboard software automatically queries the on-orbit injection usage status flag. After finding that the status flag is 0xFF, it calls the "clear on-orbit injection cache of a certain function module" interface function, which executes the following: deletes the record about the on-orbit maintenance operation of function module A in the data structure, realizes the cancellation of the on-orbit maintenance status of function module A; the on-orbit maintenance operation ends.

[0127] According to the definition in Table 6, the framing result in this step can be as shown in Table 14.

[0128] Table 14 Framed results of on-orbit maintenance status deregistration operation for function module A

[0129]

[0130] Based on Embodiments 1 and 2, taking a certain on-orbit software as an example, when it involves operations such as on-orbit maintenance of function modules, on-orbit maintenance and cancellation of batch function modules, and EEPROM write-back of injected programs, the implementation steps are summarized as shown in Table 15:

[0131] Table 15 Example Steps

[0132]

[0133]

[0134] By applying this method, attitude and orbit control application software gains the ability to record on-orbit maintenance status, effectively solving the problem of lack of monitoring and standardization in the SRAM program injection method of spaceborne software. This makes on-orbit maintenance operations more automated, simplifies the on-orbit maintenance process, and improves the on-orbit maintenance capability of spaceborne software. It also reduces the complexity of on-orbit maintenance operations for ground personnel and reduces the risk of accidents caused by human error. This invention can be extended to on-orbit maintenance operations of all spaceborne software using the "EEPROM+SRAM" storage structure.

[0135] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.

[0136] The contents not described in detail in this specification are common knowledge to those skilled in the art.

Claims

1. A method for on-orbit maintenance of spaceborne software, wherein the executable code of the spaceborne software is stored in EEPROM, and upon power-on, the executable code of the spaceborne software is read from EEPROM into SRAM, and execution of the executable code in SRAM begins; characterized in that, Including the steps for modifying the off-address program of function module A called in the onboard software: S101. The starting address, byte length Q, and compiled program code of the replacement program block InjectBlock_A used to replace function module A in SRAM are injected into the onboard software. The onboard software addresses according to the starting address of the replacement program block InjectBlock_A in SRAM and stores the compiled program code of the replacement program block InjectBlock_A into the corresponding Q consecutive memory spaces in SRAM. S102. The address of the instruction code for calling function module A in SRAM and the instruction code for calling the replacement program block InjectBlock_A are injected into the onboard software and recorded. The onboard software replaces the instruction code for calling function module A stored in SRAM with the instruction code for calling the replacement program block InjectBlock_A, thereby updating the onboard software execution code. The instruction code for calling the replacement program block InjectBlock_A performs a jump operation to the replacement program block InjectBlock_A. S103. The updated onboard software will be executed after the ground equipment uploads the enable command and enables the on-orbit maintenance operation of function module A. It also includes the step of writing the updated onboard software executable code into the EEPROM: S201. The ground equipment writes the EEPROM write-back instruction to the spaceborne software. After the spaceborne software automatically finds the EEPROM write-back instruction, it reads the recorded instruction code of the calling function module A in the EEPROM mapping address and the instruction code of the calling replacement program block InjectBlock_A. The spaceborne software performs addressing and writes the instruction code of the calling replacement program block InjectBlock_A into the EEPROM mapping address of the instruction code of the calling function module A. S202. The ground equipment injects the mapping address, byte length Q, and compiled program code of the replacement program block InjectBlock_A in the EEPROM. After receiving the program code, the onboard software addresses the program according to the mapping address of the replacement program block InjectBlock_A in the EEPROM and writes the compiled program code of the replacement program block InjectBlock_A into the corresponding Q consecutive memory spaces in the EEPROM. A three-level index data structure is established to store the records of on-orbit maintenance operations; the three-level index data structure includes an on-orbit maintenance unified management data structure, an on-orbit maintenance record data structure for function modules, and an instruction code modification record data structure. Among them: the unified management data structure for on-orbit maintenance includes a set of each on-orbit maintenance function module recorded in the on-orbit maintenance record data structure; The on-orbit maintenance record data structure for function modules is used to record the on-orbit maintenance data of a single function module, including the status flag of the on-orbit maintenance instructions, the number of instructions to be modified, and the set of instructions injected for modification in the on-orbit; wherein, the set of instructions injected for modification in the on-orbit is the set of instructions for function module A currently undergoing on-orbit maintenance, recorded in the instruction code modification record data structure; The instruction code modification record data structure is used to record single instruction code data during on-orbit maintenance of function module A, including the address of the instruction code calling function module A in SRAM, the mapping address of the instruction code calling function module A in EEPROM, the instruction code calling function module A, and the instruction code calling the replacement program block InjectBlock_A.

2. The on-orbit maintenance method for spaceborne software according to claim 1, characterized in that, The content recorded by the onboard software in S102 also includes: the mapping address of the instruction code for calling function module A in the EEPROM, and the instruction code for calling function module A; the instruction code for calling function module A is used to execute the operation of jumping to the program block of function module A.

3. The on-orbit maintenance method for spaceborne software according to claim 2, characterized in that, It also includes the step of ground equipment executing the recovery function module A to the original software state: S301. The ground equipment uploads a recovery command. After the onboard software automatically finds the recovery command, it reads the recorded instruction code of the calling function module A and the address of the instruction code of the calling function module A in the SRAM. After addressing, it writes the instruction code of the calling function module A into the address in the SRAM.

4. A method for on-orbit maintenance of spaceborne software, characterized in that, Including the in-place program modification steps for function module A called in the onboard software: S101. The number of instructions to be modified in function module A, the address of each instruction to be modified in SRAM, and the modified instruction code are written into the onboard software and recorded. The onboard software addresses according to the address of each instruction to be modified in SRAM and writes the corresponding modified instruction code into the address of the SRAM being addressed, until all instructions to be modified are replaced, thereby updating the execution code of the onboard software. S102. The updated onboard software will be executed after the ground equipment uploads the enable command and enables the on-orbit maintenance operation of function module A. It also includes the step of writing the updated onboard software execution code into the EEPROM: S201. The ground equipment writes back the EEPROM instruction to the spaceborne software. After the spaceborne software automatically finds the write back EEPROM instruction, it reads the mapping address of each instruction to be modified in the EEPROM of the recorded function module A and the modified instruction code of each instruction. It then addresses the EEPROM according to the mapping address of each instruction to be modified in the function module A and writes the corresponding modified instruction code into the mapping address of the EEPROM being addressed, until all instructions to be modified are entered. A three-level index data structure is established to store the records of on-orbit maintenance operations; the three-level index data structure includes an on-orbit maintenance unified management data structure, an on-orbit maintenance record data structure for function modules, and an instruction code modification record data structure. Among them: the unified management data structure for on-orbit maintenance includes a set of each on-orbit maintenance function module recorded in the on-orbit maintenance record data structure of the function module; The on-orbit maintenance record data structure of the function module is used to record the on-orbit maintenance data of a single function module, including the status flag of the on-orbit maintenance instructions, the number of instructions to be modified, and the set of instructions injected for modification in the on-orbit; wherein, the set of instructions injected for modification in the on-orbit is the set of instructions of function module A currently undergoing on-orbit maintenance, recorded in the instruction code modification record data structure; The instruction code modification record data structure is used to record the single instruction code data during on-orbit maintenance of function module A, including the address of each instruction to be modified in SRAM, the mapping address of each instruction to be modified in EEPROM, the instruction code before modification, and the instruction code after modification.

5. A method for on-orbit maintenance of spaceborne software according to claim 4, characterized in that, The content recorded by the S101 onboard software also includes: the mapping address of each instruction to be modified in the EEPROM of function module A, and each instruction code to be restored; the content of the instruction code to be restored is consistent with the content of the instruction code before modification.

6. A method for on-orbit maintenance of spaceborne software according to claim 5, characterized in that... It also includes the step of ground equipment executing the recovery function module A to the original software state: S301. The ground equipment uploads the recovery command. After the onboard software automatically finds the recovery command, it reads the address of each command to be modified in the SRAM of the recorded function module A and each command to be recovered. It then addresses the command according to the address of each command to be modified in the SRAM of the function module A and writes the corresponding command to be recovered into the address of the SRAM being addressed. Until all modified instruction codes have been restored.

Images