Self-adaptive recovery and reconstruction method for satellite autonomous task planning software

Abstract

A satellite autonomous task planning software self-adaptive recovery and reconstruction method comprises the steps that an autonomous task planning software health state monitoring mechanism is established, abnormal state recovery is carried out autonomously after software is abnormal, and task replanning is carried out; corresponding re-planning strategies are designed for ground task injection initiated by a user, state change of an execution mechanism of a control subsystem, whole-satellite energy safety state abnormity, attitude abnormity of the control subsystem and other states, task autonomous reconstruction is completed, and continuous operation of on-orbit tasks of the user is guaranteed. The method provided by the invention has relatively high universality and can be suitable for configuring a satellite with an on-satellite autonomous task planning function.

Description

Technical Field

[0001] The invention relates to an adaptive recovery and reconstruction method for on-board autonomous mission planning software, belonging to the technical field of on-board autonomous mission planning for satellites. Background Art

[0002] The field of autonomous onboard mission planning has developed rapidly in recent years. With the continuous advancement of satellite technology, traditional mission planning methods that rely on ground-based commands are no longer able to meet the growing demand for observation. Satellite autonomous mission planning technology has emerged to empower satellites with the ability to make independent decisions, enabling them to automatically adjust their attitude, select imaging modes, schedule data transmission and landing, and generate execution sequences based on mission requirements. This technology not only improves mission flexibility and efficiency, but also reduces reliance on ground communications, providing stronger support for emergency response.

[0003] However, the actual execution of mission planning must face a variety of complex and uncertain factors, including conflict resolution under multiple constraints, dynamic adjustment of high-level task priorities, sudden changes in user needs, and response to numerous unexpected events. These factors place extremely high demands on the stability and reliability of autonomous mission planning software.

[0004] Therefore, during the development of aerospace software products, it is necessary to build an efficient and reliable software status monitoring mechanism with functions such as real-time monitoring, exception monitoring, and risk isolation to ensure that when software operation encounters abnormalities or unexpected events, it can respond quickly to avoid adverse effects on user business. Summary of the Invention

[0005] The technical problem to be solved by the present invention is: to overcome the shortcomings of the existing technology, provide an adaptive recovery and reconstruction method for on-board autonomous mission planning software, monitor and diagnose the operating status of the autonomous mission planning software in real time, and design a recovery method after an abnormality of the autonomous mission planning software; design corresponding re-planning strategies for various input state changes during on-orbit operation, thereby completing autonomous reconstruction of the mission and ensuring the continuous operation of the user's on-orbit mission to the greatest extent.

[0006] The purpose of the present invention is achieved through the following technical solutions:

[0007] In a first aspect, a method for adaptively recovering and reconstructing onboard autonomous mission planning software comprises the following steps:

[0008] 1) Establish a health status monitoring mechanism for autonomous mission planning software

[0009] 11) Set the autonomous mission planning software health flag: The autonomous mission planning software sets the health flag Tpla.HealthFlag to indicate the autonomous mission planning software's operating status. The variable value 0xAA indicates "unhealthy" and 0xBB indicates "healthy". This variable is set to 0xBB during software initialization. This variable is a shared variable between the autonomous mission planning software and the control application software.

[0010] 12) Autonomous mission planning software operating status self-monitoring: After the autonomous mission planning software is started, the variable Tpla.HealthFlag is set to 0xBB in each planning cycle. The control application software reads this variable at a fixed period (NormalTime). If the variable is 0xBB, it is set to 0xAA. If the control application software reads the variable value as 0xAA, it sets the variable Tm.TplaHealthFlag to 1. Tm.TplaHealthFlag is transmitted to the satellite service subsystem as a telemetry parameter. 0 indicates "healthy" and 1 indicates "unhealthy".

[0011] 13) Determine the health flag Tm.TplaHealthFlag of the autonomous task planning software. If it is 1 (unhealthy), proceed to step 2); otherwise, proceed to step 3);

[0012] 2) Autonomous mission planning software abnormal state recovery and mission re-planning

[0013] 21) Setting the autonomous mission planning software to stop running and starting the autonomous mission planning software initialization process to restore the software status;

[0014] 22) To ensure the safety of all subsystems on the satellite, the control application software transmits the unhealthy status of the autonomous mission planning software health flag described in step 1) to the satellite service subsystem via the telemetry channel. After the satellite service subsystem interprets the flag, it initiates a safety shutdown command sequence for each slave computer.

[0015] 23) After the autonomous mission planning software completes the software initialization, it automatically enters the mission re-planning process and plans the most recently injected observation mission and data transmission window to ensure the continuous operation of the mission;

[0016] 3) Task re-planning during normal operation of autonomous task planning software

[0017] 31) Replanning caused by ground mission injection: The autonomous mission planning software determines whether a "user-initiated ground mission injection" event has occurred, including "ground intervention time window", "replay file retransmission within the data transmission window", "orbit control mission intervention time window", and "no ground exploration mission injection for multiple days". If so, the corresponding mission replanning logic is executed according to the event triggering situation; otherwise, the process goes to step 32).

[0018] 32) Replanning caused by change in the number of control moment gyros introduced by the control subsystem: The autonomous task planning software determines whether the "change in the number of control moment gyros introduced by the control subsystem" event occurs. If so, it runs the corresponding task replanning logic, otherwise it goes to step 33);

[0019] 33) Whole-satellite energy security anomaly monitoring and re-planning: The autonomous task planning software determines whether a "whole-satellite energy security anomaly" event has occurred. If so, it runs the corresponding task re-planning logic; otherwise, it proceeds to step 34);

[0020] 34) Control subsystem posture abnormality monitoring and re-planning: The autonomous task planning software determines whether the "control subsystem posture abnormality" event occurs. If so, it runs the corresponding task re-planning logic, otherwise returns to step 1).

[0021] Furthermore, the autonomous task planning software initialization process in step 2) is specifically as follows:

[0022]

[0023] Among them, Tpla.InitFlag is the "autonomous task planning software initialization allowed" flag, 0 means initialization is not allowed, 1 means initialization is allowed, 2 means initialization is completed, and the software defaults to 0; Tpla.CalcFlag is the "autonomous task planning software allowed" flag, 0 means "prohibited", 1 means "allowed", and the software binding value is 0; TplaAppInit() is the autonomous task planning software initialization function, which initializes the software variables and software status; TplaTask() is the main function of autonomous task planning, which contains task planning calculation-related algorithms; TplaGetData() is the important data storage function of the autonomous task planning software, which stores important parameters and variable status during the software operation, and restores the status after the software is restarted abnormally.

[0024] Furthermore, the autonomous task planning software initialization process in step 2) only restores the software running state, does not clear the parameter setting state and task injection storage, and ensures that the task execution state before the exception can be restored after re-planning.

[0025] Furthermore, in step 2), the abnormal state recovery process of the autonomous task planning software is as follows: setting Tpla.InitFlag to "allow", setting Tpla.CalcFlag to "disable", and starting the planned task. After the autonomous task planning software is started, TplaAppInit() is called to complete variable initialization; after initialization is completed, the Tpla.InitFlag flag is set to "completed"; then setting Tpla.CalcFlag to 1 "allow", the planned task can be run normally; when the Tpla.CalcFlag flag is in the disabled state, it can ensure that the variable initialization process is not interrupted by the subsequent operation of the planned task.

[0026] Furthermore, the “ground intervention time window” task injection in step 3) is specifically as follows:

[0027] The “ground intervention time window” task is injected with the start time and end time of the time window, which is recorded as: OFFTask = {ts i ,te i};

[0028] For the imaging subtask sequence of the planned task, it is recorded as: SubTask = {Flag, ID, tf i ,th i};

[0029] For each imaging subtask calculation (OFFTask.ts i -mdtfreeAdd) and SubTask.tf i The larger of the two is recorded as tmps i , calculate(OFFTask.te i +mdtfreeAdd) and SubTask.th i The smaller of the two is denoted as tmpe i , where mdtfreeAdd is used as the time margin adjustment parameter;

[0030] Determine when tmps i Less than tmpe i When the corresponding imaging subtask is valid, set the Flag i =0, indicating “invalid”, i.e. deleting the corresponding imaging subtask;

[0031] For the data transmission subtask sequence of the planned task, it is recorded as: DTTask = {Flag, ID, ts i ,te i};

[0032] For each data transmission subtask calculation (OFFTask.ts i-mdtfreeAdd) and DTTask.ts i The larger of the two is recorded as tmps i , calculate(OFFTask.te i +mdtfreeAdd) and DTTask.te i The smaller of the two is denoted as tmpe i , where mdtfreeAdd is used as the time margin adjustment parameter;

[0033] Determine when tmps i Less than tmpe i When the corresponding data transmission subtask is valid, set the Flag i =0, means "invalid", that is, the corresponding data transmission subtask is deleted.

[0034] Furthermore, the task injection of "playing back the file in the data transmission window and re-uploading" in step 3) is specifically as follows:

[0035] The task of "playing back the file in the data transmission window and retransmitting it" is injected with the number of retransmission windows and the ID of the specified retransmission window, which is recorded as: WinRePlay = {Num, ID i};

[0036] Determine ID i If the status flag F_Play of the file to be replayed arranged in the corresponding data transmission window is "playback completed", the flag will be set to "waiting for playback". The data transmission playback task planning process will arrange the file marked as "waiting for playback" to be replayed again in the subsequent available data transmission window.

[0037] Furthermore, the “orbit control task intervention time window” in step 3) is specifically:

[0038] The “orbit control intervention time window” task is injected with the start time and end time of the time window, which is recorded as: OrbitControlTask ​​= {ts i ,te i};

[0039] For each imaging subtask calculation (OrbitControlTask.ts i -mdtfreeAdd) and SubTask.tf i The larger of the two is recorded as tmps i , calculate (OrbitControlTask.te i +mdtfreeAdd) and SubTask.th i The smaller of the two is denoted as tmpe i ;

[0040] Determine when tmps i Less than tmpe i When the corresponding imaging subtask is valid, set the Flag i =0, indicating “invalid”, i.e. deleting the corresponding imaging subtask;

[0041] For each data transmission subtask calculation (OrbitControlTask.ts i -mdtfreeAdd) and DTTask.ts i The larger of the two is recorded as tmps i , calculate (OrbitControlTask.te i +mdtfreeAdd) and DTTask.te i The smaller one is denoted as tmpe i ;

[0042] Determine when tmps i Less than tmpe i When the corresponding data transmission subtask is valid, set the Flag i =0, means "invalid", that is, the corresponding data transmission subtask is deleted.

[0043] During the orbit control window, the ground satellite control center can take over the control of the satellite and implement orbit control tasks. After the window period ends, the planning software determines whether it has received the orbit injection after the orbit change. After receiving it, it will autonomously enter the mission re-planning and resume the autonomous operation of subsequent tasks.

[0044] Furthermore, the “multi-day no ground detection mission injection” in step 3) is specifically as follows:

[0045] When the autonomous mission planning software determines that no observation mission has been received from the ground for N consecutive days, it automatically enters mission replanning, selects fixed targets in the target library, and autonomously arranges fixed target observation tasks; and based on the information of the dedicated data transmission station, it autonomously calculates the available data transmission resources and arranges data transmission ground playback tasks; this function can be enabled or not by the user.

[0046] Furthermore, in step 3), the replanning caused by the change in the number of control moment gyros introduced by the control subsystem is specifically as follows:

[0047] The autonomous mission planning software sets the flag Fi_CMGRePlan to indicate "allowing CMG introduction status changes to trigger replanning." When the flag is 1, it indicates permission, i.e., monitoring the number of CMG introductions and replanning missions when the number of introductions changes.

[0048] The autonomous mission planning software determines the value of the variable N_CMG every cycle. When N_CMG is less than N_CMGpst, it is determined that a CMG fault has occurred in the control system and has been removed. F_PlanBreak is set to 1, indicating that the planned mission is suspended, and the current satellite time is recorded as t_planbreak. The corresponding attitude maneuverability parameters are set according to the value of N_CMG.

[0049] After the CMG is removed, the control application software starts the CMG autonomous running-in process. After the autonomous mission planning software determines that the faulty CMG has slid into place, it sets F_PlanBreak to 0 and enters mission replanning according to the maneuverability corresponding to the current number of CMGs to resume mission execution.

[0050] When it is determined that the faulty CMG has completed running-in and accelerated to the nominal speed, F_PlanBreak is set to 1 and the planned task execution is tentatively scheduled; when N_CMG is greater than or equal to N_CMGpst, it is determined that the CMG status has been restored, the autonomous task planning software sets F_PlanBreak to 0, and enters task re-planning according to the maneuverability corresponding to the current number of CMGs, and resumes task execution.

[0051] Furthermore, the whole-star energy security abnormality monitoring and re-planning in step 3) is specifically as follows:

[0052] The autonomous mission planning software receives real-time telemetry of the satellite's "current battery power" transmitted by the satellite service subsystem, recorded as Fi_Power, and determines the discharge depth of the satellite's power supply. When the discharge depth reaches the maximum allowable discharge depth threshold, max_Power, the planning software completes the execution of the current task, clears subsequent tasks to be executed, outputs the control subsystem's Sun-Earth conversion task, and switches the control subsystem's working mode WorkMode to "Sun-orientation mode" to charge the entire satellite's battery. When it is determined that the battery power has reached the normal operation threshold, min_Power, the planning software automatically enters mission replanning, plans the most recently injected observation task and data transmission window, and restores the normal operation of the mission.

[0053] Furthermore, the control subsystem posture abnormality monitoring and re-planning in step 3) is specifically as follows:

[0054] The planning software determines the operating status of the control subsystem in real time. When the WorkMode changes to "full attitude capture mode", the planning software immediately stops the current task and clears subsequent tasks to be executed. When the WorkMode changes to "solar orientation mode" or "earth orientation mode", the planning software automatically enters task replanning, plans the most recently injected observation task and data transmission window, and restores the normal operation of the task. The user can set whether to enable or disable autonomous task recovery.

[0055] According to a second aspect, a computer program product is provided. The computer program product comprises instructions. When the computer program product is run on a computer, the computer is caused to execute the method according to the first aspect.

[0056] Compared with the prior art, the present invention has the following beneficial effects:

[0057] (1) The present invention proposes an adaptive and reconstructive method for autonomous task planning software, which monitors and diagnoses the running status of the autonomous task planning software in real time by controlling the application software, and designs a recovery method after software anomalies. The design of the health diagnosis mechanism ensures the reliable operation of autonomous task planning.

[0058] (2) The present invention designs effective response and processing strategies for various state changes on orbit, autonomously completes task reconstruction, and avoids user tasks being affected or even interrupted during on-orbit application. BRIEF DESCRIPTION OF THE DRAWINGS

[0059] Figure 1 The figure is a flowchart of the adaptive recovery and reconstruction method for onboard autonomous mission planning software of the present invention. DETAILED DESCRIPTION

[0060] To make the objectives, technical solutions and advantages of the present invention more clear, the embodiments of the present invention will be described in further detail below with reference to the accompanying drawings.

[0061] A method for adaptively recovering and reconstructing onboard autonomous mission planning software includes establishing a health monitoring mechanism for the autonomous mission planning software, autonomously recovering from abnormal conditions and replanning the mission after a software anomaly occurs, and designing corresponding re-planning strategies for conditions such as user-initiated ground mission injection, changes in the control subsystem's actuator status, abnormalities in the satellite's energy security status, and abnormalities in the control subsystem's attitude. This method allows for autonomous mission reconstruction and ensures the continuous operation of the user's on-orbit mission. The method proposed in this invention is highly versatile and applicable to satellites equipped with onboard autonomous mission planning capabilities.

[0062] The specific steps are:

[0063] 1) Establish a health status monitoring mechanism for autonomous mission planning software

[0064] The autonomous mission planning software of the present invention runs in the satellite attitude and orbit control subsystem control computer, interacts with the control application software for software status, and the control application software is responsible for the communication function with the satellite space service subsystem. Figure 1 shown.

[0065] 11) Set the healthy operation flag of autonomous task planning software

[0066] The autonomous mission planning software sets the health flag Tpla.HealthFlag to indicate the software's operating status. A variable value of 0xAA indicates "unhealthy" and 0xBB indicates "healthy." This variable is set to 0xBB during software initialization. This variable is a shared variable between the autonomous mission planning software and the control application software.

[0067] 12) Autonomous mission planning software operating status self-monitoring

[0068] After the autonomous mission planning software is started, the variable Tpla.HealthFlag is set to 0xBB in each planning cycle. The control application software reads this variable every fixed period NormalTime (set to 20 minutes in this example). If the variable is 0xBB, it is set to 0xAA. If the control application software reads the variable value as 0xAA, it sets the variable Tm.TplaHealthFlag to 1. Tm.TplaHealthFlag is transmitted to the spacecraft subsystem as a telemetry parameter. 0 indicates "healthy" and 1 indicates "unhealthy".

[0069] 13) If the autonomous task planning software health flag Tm.TplaHealthFlag is 1 (unhealthy), proceed to step 2; otherwise, proceed to step 3.

[0070] 2) Autonomous mission planning software abnormal state recovery and mission re-planning

[0071] 21) Setting the autonomous mission planning software to stop running and starting the autonomous mission planning software initialization process to restore the software status;

[0072] 22) To ensure the safety of all subsystems on the satellite, the control application software transmits the unhealthy status of the autonomous mission planning software health flag described in step 1) to the satellite service subsystem via the telemetry channel. After the satellite service subsystem interprets the flag, it initiates a safety shutdown command sequence for each slave computer.

[0073] 23) After the autonomous mission planning software completes the software initialization, it automatically enters the mission re-planning process and plans the most recently injected observation mission and data transmission window to ensure the continuous operation of the mission;

[0074] Step 2) The abnormal state self-recovery logic design of the autonomous task planning software is as follows:

[0075] When the variable Tpla.InitFlag is 1 and the variable Tpla.CalcFlag is 0, call the TplaAppInit function and set the variable Tpla.InitFlag to 2;

[0076] When the variable Tpla.InitFlag is 2 and the variable Tpla.CalcFlag is 1, call the TplaGetData function and then call the TplaTask function;

[0077] Among them, Tpla.InitFlag is the "autonomous task planning software initialization allowed" flag, 0 means initialization is not allowed, 1 means initialization is allowed, 2 means initialization is completed, and the software defaults to 0; Tpla.CalcFlag is the "autonomous task planning software allowed" flag, 0 means "prohibited", 1 means "allowed", and the software binding value is 0; TplaAPPInit is the autonomous task planning software initialization function, which initializes the software variables and software status; TplaTask is the main function of autonomous task planning, which contains task planning calculation-related algorithms; TplaGetData is the important data storage function of the autonomous task planning software, which stores important parameters and variable status during the software operation, and restores the status after the software is restarted abnormally.

[0078] Step 2) The autonomous task planning software initialization process only restores the software running state, does not clear the parameter setting state and task injection storage, and ensures that the task execution state before the abnormality can be restored after re-planning.

[0079] Step 2) The abnormal state recovery process of the autonomous task planning software is as follows: set Tpla.InitFlag to "allow", set Tpla.CalcFlag to "disable", and start the planned task. After the autonomous task planning software is started, call TplaAPPInit to complete variable initialization; after initialization is completed, the Tpla.InitFlag flag is set to "completed"; then set Tpla.CalcFlag to 1 "allow", and the planned task can be run normally; when the Tpla.CalcFlag flag is in the disabled state, it can ensure that the variable initialization process is not interrupted by the subsequent operation of the planned task.

[0080] 3) Task re-planning during normal operation of autonomous task planning software

[0081] 31) Replanning caused by ground mission injection

[0082] The autonomous mission planning software receives tasks such as "ground intervention time window", "replay file retransmission within the data transmission window", and "orbit control mission intervention" from the user's ground system, and replans tasks according to the corresponding windows to achieve autonomous mission control of the coexistence of satellite and ground missions, and autonomously plans for the situation of "no ground detection mission injection for many days". The autonomous mission planning software determines whether the above time occurs. If so, it runs the corresponding mission replanning logic according to the event triggering situation; otherwise, it enters step 32);

[0083] The “ground intervention time window” task injection is specifically as follows:

[0084] For the "Ground Intervention Time Window" task injection, after receiving the task, the autonomous task planning software enters task re-planning and does not schedule any tasks during the time period specified in the window. During this period, users can temporarily take over the control of satellite tasks through the ground system to implement temporary ground tasks and emergency observation tasks, etc., without affecting the normal execution of subsequent autonomous tasks. Specifically:

[0085] The “ground intervention time window” task is injected with the start time and end time of the time window, which is recorded as: OFFTask = {offtask_ts i ,offtask_te i};

[0086] For the imaging subtask sequence of the planned task, it is recorded as:

[0087] SubTask={subtask_Flag i ,subtask_ID i ,tf i ,th i}, where subtask_Flag i Indicates the valid flag of the imaging subtask, subtask_ID i Indicates the imaging subtask code, tf i Indicates the imaging subtask imaging start time, th i Indicates the imaging end time of the imaging subtask;

[0088] For each imaging subtask calculation (offtask_ts i -mdtfreeAdd) and tf i The larger of the two is recorded as tmps i , calculate (offtask_te i +mdtfreeAdd)with th i The smaller of the two is denoted as tmpe i , where mdtfreeAdd is the time margin adjustment parameter and is set to 300s in this example;

[0089] Determine when tmps i Less than tmpe i When the corresponding imaging subtask is valid, set the Flag i =0, indicating “invalid”, i.e. deleting the corresponding imaging subtask;

[0090] For the data transmission subtask sequence of the planned task, it is recorded as:

[0091] DTTask = {dttask_Flag i ,dttask_ID i ,dttask_ts i ,dttask_te i}, where dttask_Flag i surface

[0092] Indicates the valid flag of the data transmission subtask, dttask_ID i Indicates the data transmission subtask code, dttask_ts i Indicates the start time of the data transmission subtask, dttask_te i Indicates the end time of the data transmission subtask;

[0093] For each data transmission subtask calculation (offtask_ts i -mdtfreeAdd) and dttask_ts i The larger of the two is recorded as tmps i , calculate (offtask_te i +mdtfreeAdd) and dttask_te i The smaller of the two is denoted as tmpe i , where mdtfreeAdd is the time margin adjustment parameter and is set to 300s in this example;

[0094] Determine when tmps i Less than tmpe i When the corresponding data transmission subtask is valid, set the Flag i =0, means "invalid", that is, the corresponding data transmission subtask is deleted.

[0095] The task injection of "playing back files in the data transmission window and re-uploading" is specifically as follows:

[0096] For the task injection of "replay file retransmission within the data transmission window", the user injects it after determining that the ground station data reception is abnormal. After receiving the window task, the planning software replans the data transmission task, combines the user-specified retransmission file with the current data transmission window resources, and replans the data transmission playback task. Specifically:

[0097] The task of "playing back the file in the data transmission window and retransmitting it" is injected with the number of retransmission windows and the ID of the specified retransmission window, which is recorded as: WinRePlay = {Num, ID i};

[0098] Determine ID iIf the status flag F_Play of the file to be replayed arranged in the corresponding data transmission window is "playback completed", the flag will be set to "waiting for playback". The data transmission playback task planning process will arrange the file marked as "waiting for playback" to be replayed again in the subsequent available data transmission window.

[0099] The task injection of the “orbit control task intervention time window” is specifically as follows:

[0100] When the ground satellite control center assigns an orbit control task based on the satellite's orbit change requirements, it simultaneously assigns the "orbit control intervention time window" to the autonomous task planning software. After receiving the task, the software immediately clears the task sequence after the specified start time. Specifically:

[0101] The “orbit control intervention time window” task is injected with the start time and end time of the time window, which is recorded as: OrbitControlTask ​​= {oc_ts i ,oc_te i};

[0102] For each imaging subtask calculate (oc_ts i -mdtfreeAdd) and tf i The larger of the two is recorded as tmps i , calculate (oc_te i +mdtfreeAdd)with th i The smaller of the two is denoted as tmpe i ;

[0103] Determine when tmps i Less than tmpe i When the corresponding imaging subtask is valid, set the Flag i =0, indicating “invalid”, i.e. deleting the corresponding imaging subtask;

[0104] For each data transmission subtask calculation (oc_ts i -mdtfreeAdd) and dttask_ts i The larger of the two is recorded as tmps i , calculate (oc_te i +mdtfreeAdd) and dttask_te i The smaller of the two is denoted as tmpe i ;

[0105] Determine when tmps i Less than tmpe i When the corresponding data transmission subtask is valid, set the Flag i =0, means "invalid", that is, the corresponding data transmission subtask is deleted.

[0106] During the orbit control window, the ground satellite control center can take over the control of the satellite and implement orbit control tasks. After the window period ends, the planning software determines whether it has received the orbit injection after the orbit change. After receiving it, it will autonomously enter the mission re-planning and resume the autonomous operation of subsequent tasks.

[0107] The “multi-day non-ground detection mission injection” is specifically:

[0108] When the autonomous mission planning software determines that no observation missions have been received from the ground for N consecutive days (set to 7 in this example), it automatically enters mission replanning, selects fixed targets in the target library, and autonomously arranges fixed target observation missions. It also autonomously calculates available data transmission resources based on information from dedicated data transmission stations and arranges data transmission ground playback missions. This function can be enabled or disabled by the user.

[0109] 32) Replanning caused by changes in the number of control torque gyros

[0110] The control subsystem configures control moment gyros (CMGs) as actuators. The number of CMGs introduced into control is defined as N_CMG, and the number of CMGs introduced in the nominal state is defined as N_CMGpst. In this example, the default value is 5. During on-orbit operation, the control subsystem diagnoses and removes control of any CMG failures, while also setting the corresponding attitude maneuverability parameters. The autonomous mission planning software determines whether a "change in the number of control moment gyros introduced into the control subsystem" event has occurred. If so, it executes the corresponding mission replanning logic; otherwise, it proceeds to step 33.

[0111] The replanning caused by the change in the number of control moment gyroscopes is specifically:

[0112] The autonomous mission planning software sets the flag Fi_CMGRePlan to indicate "allowing CMG introduction status changes to trigger replanning." When the flag is 1, it indicates permission, i.e., monitoring the number of CMG introductions and replanning missions when the number of introductions changes.

[0113] The autonomous mission planning software determines the value of the variable N_CMG every cycle. When N_CMG is less than N_CMGpst, it is determined that a CMG failure has occurred in the control system and has been removed. F_PlanBreak is set to 1, indicating that the planned mission is suspended, and the current star time is recorded as t_planbreak. The corresponding attitude maneuverability parameters are set according to the value of N_CMG, where mvk_5CMG represents the attitude maneuverability parameters when 5 CMGs are introduced, and mvk_4CMG represents the attitude maneuverability parameters when 4 CMGs are introduced. When N_CMG is less than 3, subsequent mission planning is no longer carried out.

[0114] After the CMG is removed, the control application software starts the CMG autonomous run-in process. The autonomous mission planning software determines whether the faulty CMG has coasted into place. That is, when the CMG high-speed speed is less than 100 rpm and the difference between t_planbreak and the current satellite time is less than mdt_CMG0 (representing the CMG coasting time threshold, set to 3000s in this example), it sets F_PlanBreak to 0, enters mission replanning according to the maneuverability corresponding to the current number of CMGs, and resumes mission execution.

[0115] When it is determined that the high-speed speed of the faulty CMG rises to 200rpm (the CMG will accelerate to the nominal speed after completing the running-in), F_PlanBreak is set to 1, and the planned task execution is tentatively scheduled; when N_CMG is greater than or equal to N_CMGpst, it is determined that the CMG status has been restored, the autonomous task planning software sets F_PlanBreak to 0, and enters task re-planning according to the maneuverability corresponding to the current number of CMGs, and resumes task execution.

[0116] 33) Re-planning of the whole-star energy security monitoring:

[0117] The autonomous mission planning software determines whether a "whole-satellite energy security anomaly" event has occurred. If so, it runs the corresponding mission replanning logic; otherwise, it proceeds to step 34);

[0118] The above-mentioned re-planning of the whole-star energy security monitoring is as follows:

[0119] The autonomous mission planning software receives real-time telemetry of the satellite's "current battery power" transmitted by the satellite service subsystem, recorded as Fi_Power, and determines the discharge depth of the satellite's power supply. When the discharge depth reaches the maximum allowable discharge depth threshold, max_Power, the planning software completes the execution of the current task, clears subsequent tasks to be executed, outputs the control subsystem's Sun-Earth conversion task, and switches the control subsystem's working mode WorkMode to "Sun-orientation mode" to charge the entire satellite's battery. When it is determined that the battery power has reached the normal operation threshold, min_Power, the planning software automatically enters mission replanning, plans the most recently injected observation task and data transmission window, and restores the normal operation of the mission.

[0120] 34) Abnormal posture monitoring and re-planning

[0121] The autonomous mission planning software determines whether the "control subsystem posture abnormality" event occurs. If so, it runs the corresponding mission replanning logic, otherwise returns to step 1);

[0122] The posture abnormality monitoring and re-planning is specifically as follows:

[0123] The planning software determines the operating status of the control subsystem in real time. When the WorkMode changes to "full attitude capture mode", the planning software immediately stops the current task and clears subsequent tasks to be executed. When the WorkMode changes to "solar orientation mode" or "earth orientation mode", the planning software automatically enters task replanning, plans the most recently injected observation task and data transmission window, and restores the normal operation of the task. The user can set whether to enable or disable autonomous task recovery.

[0124] The contents not described in detail in the specification of the present invention belong to the common knowledge of those skilled in the art.

[0125] Although the present invention has been disclosed above in terms of preferred embodiments, it is not intended to limit the present invention. Any person skilled in the art may make possible changes and modifications to the technical solutions of the present invention by using the methods and technical contents disclosed above without departing from the spirit and scope of the present invention. Therefore, any simple modifications, equivalent changes and modifications made to the above embodiments based on the technical essence of the present invention without departing from the content of the technical solutions of the present invention shall fall within the scope of protection of the technical solutions of the present invention.

Claims

1. A method for adaptive recovery and reconstruction of onboard autonomous mission planning software, characterized in that: include: S1. Establish a health status monitoring mechanism for autonomous task planning software, as follows: 11) Set the healthy operation flag of the autonomous task planning software: The autonomous task planning software sets the healthy operation flag Tpla.HealthFlag, which indicates the running status of the autonomous task planning software. The variable value 0xAA indicates "unhealthy" and 0xBB indicates "healthy". The variable is set to 0xBB when the software is initialized; this variable is a shared variable between the autonomous task planning software and the control application software; 12) Self-monitoring of the running status of the autonomous mission planning software: After the autonomous mission planning software is started, the variable Tpla.HealthFlag is set to 0xBB in each planning cycle. The control application software reads the variable at a fixed period NormalTime. If the variable is 0xBB, the variable is set to 0xAA. If the control application software reads the variable value as 0xAA, the variable Tm.TplaHealthFlag is set to 1. Tm.TplaHealthFlag is transferred to the satellite service subsystem as a telemetry parameter. 0 means "healthy" and 1 means "unhealthy"; 13) Determine the health flag Tm.TplaHealthFlag of the autonomous task planning software. If it is 1 (unhealthy), proceed to step S2; otherwise, proceed to step S3; S2. Autonomous task planning software abnormal state recovery and task re-planning, as follows: 21) Set the autonomous task planning software to stop running, and start the autonomous task planning software initialization process to restore the software status; 22) To ensure the safety of all subsystems of the entire satellite, the control application software transmits the unhealthy state of the health flag of the autonomous mission planning software described in step S1 to the satellite service subsystem through the telemetry channel. After the satellite service subsystem reads the flag, it initiates a safety shutdown command sequence for each lower computer; 23) After the autonomous task planning software completes the software initialization, it automatically enters the task re-planning and plans the observation task and data transmission window injected most recently to ensure the continuous operation of the task; S3: Re-planning of tasks during the normal operation of the autonomous task planning software, as follows: 31) Re-planning caused by ground mission injection: The autonomous mission planning software determines whether a "user-initiated ground mission injection" event occurs, including "ground intervention time window", "re-transmission of playback files within the data transmission window", "orbit control mission intervention time window", and "no ground detection mission injection for multiple days"; If yes, then run the corresponding task re-planning logic according to the event triggering situation, otherwise go to step 32); 32) Replanning caused by change in the number of control moment gyros introduced by the control subsystem: The autonomous task planning software determines whether the "change in the number of control moment gyros introduced by the control subsystem" event occurs. If so, the corresponding task replanning logic is run, otherwise it goes to step 33); 33) Whole-star energy security anomaly monitoring and re-planning: The autonomous task planning software determines whether the "whole-star energy security anomaly" event occurs. If so, the corresponding task re-planning logic is run, otherwise it goes to step 34); 34) Control subsystem posture abnormality monitoring and re-planning: The autonomous task planning software determines whether the "control subsystem posture abnormality" event occurs. If so, it runs the corresponding task re-planning logic, otherwise returns to step S1.

2. The method for adaptively restoring and reconstructing on-board autonomous mission planning software according to claim 1, characterized in that: The abnormal state self-recovery logic of the autonomous task planning software is as follows: When the variable Tpla.InitFlag is 1 and the variable Tpla.CalcFlag is 0, call the TplaAppInit function and set the variable Tpla.InitFlag to 2; When the variable Tpla.InitFlag is 2 and the variable Tpla.CalcFlag is 1, call the TplaGetData function, and then call the TplaTask function; Among them, Tpla.InitFlag is the "autonomous task planning software initialization allowed" flag, 0 means initialization is not allowed, 1 means initialization is allowed, 2 means initialization is completed, and the software defaults to 0; Tpla.CalcFlag is the "autonomous task planning software allowed" flag, 0 means "prohibited", 1 means "allowed", and the software binding value is 0; TplaAPPInit is the autonomous task planning software initialization function, which initializes the software variables and software status; TplaTask is the main function of autonomous task planning, which contains task planning calculation-related algorithms; TplaGetData is the important data storage function of the autonomous task planning software, which stores important parameters and variable status during the software operation, and restores the status after the software is restarted abnormally.

3. The method for adaptively restoring and reconstructing on-board autonomous mission planning software according to claim 1, characterized in that: The autonomous task planning software initialization process only restores the software running status, does not clear the parameter setting status and task injection storage, and ensures that the task execution status before the exception can be restored after re-planning.

4. The method for adaptively restoring and reconstructing on-board autonomous mission planning software according to claim 2, characterized in that: The abnormal state recovery process of the autonomous task planning software is as follows: set Tpla.InitFlag to "allow", set Tpla.CalcFlag to "prohibit", and start the planning task. After the autonomous task planning software is started, call TplaAPPInit to complete variable initialization; after initialization is completed, the Tpla.InitFlag flag is set to "completed"; then set Tpla.CalcFlag to 1 "allow", and the planning task can be run normally; when the Tpla.CalcFlag flag is in the prohibited state, it can ensure that the variable initialization process is not interrupted by the subsequent operation of the planning task.

5. The method for adaptively restoring and reconstructing on-board autonomous mission planning software according to claim 1, characterized in that: The "ground intervention time window" task injection is specifically: For the task injection of "ground intervention time window", after receiving the task, the autonomous task planning software enters task re-planning and does not arrange any tasks in the time period specified in the window. During this period, the user can temporarily take over the control of satellite tasks through the ground system to implement temporary ground tasks and emergency observation tasks, etc., which will not affect the normal execution of subsequent autonomous tasks. Specifically: The "ground intervention time window" task is injected with the start time and end time of the time window, recorded as: OFFTask = {offtask_ts i ,offtask_te i }; For the imaging subtask sequence of the planned task, it is recorded as: SubTask = {subtask_Flag i ,subtask_ID i ,tf i ,th i }, where subtask_Flag i Indicates the effective flag of the imaging subtask, subtask_ID i Indicates the imaging subtask code, tf i Indicates the imaging start time of the imaging subtask, th i Indicates the imaging end time of the imaging subtask; For each imaging subtask calculation (offtask_ts i -mdtfreeAdd) and tf i The larger of the two is recorded as tmps i , calculate (offtask_te i +mdtfreeAdd) and th i The smaller of i , where mdtfreeAdd is the time margin adjustment parameter, which is set to 300s in this example; Determine when tmps i Less than tmpe i When the corresponding imaging subtask is valid, set the Flag i =0, indicating "invalid", i.e. deleting the corresponding imaging subtask; For the data transmission subtask sequence of the planned task, it is recorded as: DTTask = {dttask_Flag i , dttask_ID i , dttask_ts i , dttask_te i}, where dttask_Flag i Table Indicates the valid flag of the digital transmission subtask, dttask_ID i Indicates the data transmission subtask code, dttask_ts i Indicates the start time of the data transmission subtask, dttask_te i Indicates the end time of the data transmission subtask; For each data transmission subtask calculation (offtask_ts i -mdtfreeAdd) and dttask_ts i The larger of the two is recorded as tmps i , calculate (offtask_te i +mdtfreeAdd) and dttask_te i The smaller of i , where mdtfreeAdd is used as the time margin adjustment parameter; Determine when tmps i Less than tmpe i When the corresponding data transmission subtask is valid, set the Flag i =0, means "invalid", that is, delete the corresponding data transmission subtask.

6. The method for adaptively restoring and reconstructing on-board autonomous mission planning software according to claim 1, characterized in that: The playback file re-upload task injection in the data transmission window is as follows: For the task injection of "re-transmitting playback files in the data transmission window", the user injects it after judging that the ground station data reception is abnormal. After receiving the window task, the planning software re-plans the data transmission task, combines the retransmission file specified by the user with the current data transmission window resources, and re-plans the data transmission playback task. Specifically: The task of "playing back the file in the data transmission window and retransmitting it" is injected with the number of retransmission windows and the specified retransmission data transmission window ID as: WinRePlay = {Num, ID i }; Determine ID i If the status flag F_Play of the file to be played back arranged in the corresponding data transmission window is "playback completed", the flag will be set to "to be played back". The data transmission playback task planning process will arrange the file marked as "to be played back" to be played back again in the subsequent available data transmission window.

7. The method for adaptively restoring and reconstructing on-board autonomous mission planning software according to claim 1, characterized in that: The orbit control task intervenes in the time window task injection, specifically: When the ground satellite control center adds the orbit control task according to the satellite orbit change requirements, it will simultaneously add the "orbit control intervention time window" to the autonomous task planning software. After receiving the task, the software will immediately clear the task sequence after the specified start time of the task, specifically: The "orbit control intervention time window" task is injected with the start time and end time of the time window, recorded as: OrbitControlTask ​​= {oc_ts i ,oc_te i }; For each imaging subtask, calculate (oc_ts i -mdtfreeAdd) and tf i The larger of the two is recorded as tmps i , calculate (oc_te i +mdtfreeAdd) and th i The smaller of i ; Determine when tmps i Less than tmpe i When the corresponding imaging subtask is valid, set the Flag i =0, indicating "invalid", i.e. deleting the corresponding imaging subtask; For each data transmission subtask calculation (oc_ts i -mdtfreeAdd) and dttask_ts i The larger of the two is recorded as tmps i , calculate (oc_te i +mdtfreeAdd) and dttask_te i The smaller of i ; Determine when tmps i Less than tmpe i When the corresponding data transmission subtask is valid, set the Flag i =0, means "invalid", that is, delete the corresponding data transmission subtask.

8. The method for adaptively restoring and reconstructing on-board autonomous mission planning software according to claim 1, characterized in that: The multi-day non-ground detection mission injection is specifically: When the autonomous task planning software determines that no observation tasks have been received from the ground for N consecutive days, it automatically enters task re-planning, selects fixed targets in the target library, and autonomously arranges fixed target observation tasks; Based on the information from the dedicated data transmission station, it can autonomously calculate the available data transmission resources and arrange the data transmission playback tasks to the ground.

9. The method for adaptively restoring and reconstructing on-board autonomous mission planning software according to claim 1, characterized in that: The control moment gyro introduces replanning caused by the change in quantity, specifically: The autonomous task planning software sets the flag Fi_CMGRePlan to indicate "allowing CMG to introduce state changes to trigger replanning". When the flag is 1, it means it is allowed, that is, monitoring the number of CMG introductions and replanning the task when the number of introductions changes; The autonomous task planning software determines the value of the variable N_CMG every cycle. When N_CMG is less than N_CMGpst, it is determined that a CMG failure has occurred in the control system and has been removed. F_PlanBreak is set to 1, indicating that the planned task is suspended, and the current star time is recorded as t_planbreak. According to the value of N_CMG, the corresponding attitude maneuverability parameters are set, where mvk_5CMG represents the attitude maneuverability parameters when 5 CMGs are introduced, and mvk_4CMG represents the attitude maneuverability parameters when 4 CMGs are introduced. When it is determined that N_CMG is less than 3, no subsequent task planning will be performed. After the CMG is removed, the control application software starts the CMG autonomous running-in process. The autonomous task planning software determines whether the faulty CMG has glided into place, that is, when the CMG high-speed speed is less than 100rpm and the difference between t_planbreak and the current satellite time is less than mdt_CMG0 (indicating the CMG gliding time threshold, which is set to 3000s in this example), F_PlanBreak is set to 0, and the task re-planning is performed according to the maneuverability corresponding to the current number of CMGs to resume task execution; When it is determined that the high-speed speed of the faulty CMG rises to the nominal speed, F_PlanBreak is set to 1 and the planned task is temporarily executed; when N_CMG is greater than or equal to N_CMGpst, it is determined that the CMG status has been restored, the autonomous task planning software sets F_PlanBreak to 0, and enters task re-planning according to the maneuverability corresponding to the current number of CMGs, and resumes task execution.

10. The method for adaptively restoring and reconstructing on-board autonomous mission planning software according to claim 1, characterized in that: The overall energy security monitoring re-planning is as follows: The autonomous mission planning software receives the telemetry of the "current battery power" of the whole satellite transmitted by the satellite service subsystem in real time, recorded as Fi_Power, and determines the discharge depth of the whole satellite power supply; when the discharge depth reaches the maximum allowable discharge depth threshold max_Power, the planning software completes the execution of the current task, clears the subsequent tasks to be executed, outputs the control subsystem's sun-earth conversion task, and controls the subsystem's working mode WorkMode to enter the "solar orientation mode", and the whole satellite charges the battery; when it is determined that the battery power reaches the threshold min_Power for normal operation, the planning software automatically enters the task re-planning, plans the most recently injected observation task and data transmission window, and restores the normal operation of the task.

11. The method for adaptively restoring and reconstructing on-board autonomous mission planning software according to claim 1, characterized in that: The posture abnormality monitoring re-planning is specifically as follows: The planning software determines the operating status of the control subsystem in real time. When the WorkMode changes to "full attitude capture mode", the planning software immediately stops the current task and clears subsequent tasks to be executed; when it is determined that the WorkMode changes to "solar orientation mode" or "earth orientation mode", the planning software automatically enters task re-planning, plans the most recently injected observation task and data transmission window, and restores the normal operation of the task.

Images