A multi-satellite mission planning system and method

Abstract

This invention discloses a multi-satellite mission planning system and method, belonging to the field of on-board mission planning. The mission planning module allocates at least one execution satellite for each specified mission based on the mission request, the current orbital information of each satellite, and current resource information, generating a mission planning scheme. When the cloud core node establishes communication with any execution satellite, it generates the corresponding mission instruction and sends it to the edge core node of that execution satellite. When the edge core node establishes communication with the ground terminal, it receives and parses the mission instruction from the ground terminal and registers the timing trigger information to the local timing scheduler. The edge core node, through the local timing scheduler, creates and runs the container image of the corresponding specified mission when the planned execution time arrives, to execute the specified mission. This invention overcomes the problem of mission triggering and timing control being impossible due to the inevitable interruptions and delays in satellite-to-ground communication.

Description

Technical Field

[0001] This invention belongs to the field of on-board mission planning, specifically relating to a multi-satellite mission planning system and method. Background Technology

[0002] With the rapid development of satellite technology and the increasing demands for its applications, on-board computing and on-orbit mission execution have become important research directions in scenarios such as Earth observation and emergency response. Satellite systems are gradually evolving from single data acquisition platforms to those with on-orbit processing and collaborative computing capabilities, in order to achieve lower latency information extraction and more efficient resource utilization.

[0003] However, because satellites operate in predetermined orbits, their visibility window with ground stations is limited, leading to periodic interruptions in communication links. Under these conditions, satellites are offline most of the time, unable to receive instructions or updates from ground control centers in real time, and lack local timed scheduling capabilities. This makes it difficult to guarantee the timely initiation and completion of tasks that need to be performed within specific time windows (such as when a satellite passes over a target area). Summary of the Invention

[0004] The purpose of this invention is to provide a multi-satellite mission planning system and method that can solve the problems existing in the background art.

[0005] To solve the above-mentioned technical problems, the present invention is implemented as follows: In a first aspect, embodiments of the present invention provide a multi-satellite mission planning system, including a ground terminal and multiple satellites; the ground terminal includes a mission planning module and a cloud core node; each of the satellites is deployed with an edge core node, and the edge core node is configured with a local timing scheduler. The mission planning module is used to allocate at least one execution satellite covering its mission area and meeting its resource requirements for each specified mission based on the mission request containing multiple specified missions, the current orbit information and current resource information of each satellite, and to generate a mission planning scheme. The cloud core node is used to generate corresponding task instructions and send them to the edge core node of the execution satellite, based on the task planning scheme and the planned execution time of each specified task to be executed on the execution satellite, when communication is established with any execution satellite. The task instructions include: the container image identifier of the specified task, the container image configuration parameters, and timed trigger information for indicating the planned execution time of the specified task. The planned execution time of each specified task is located within the time period between the current time and the next time the execution satellite establishes communication with the ground terminal. The edge core node is used to receive and parse the mission instructions from the ground terminal when communication is established between the local satellite and the ground terminal, and to register the timing trigger information to the local timing scheduler. The edge core node, through the local timer scheduler, creates and runs a container image of the corresponding designated task when the scheduled execution time arrives, based on the timed trigger information, to execute the designated task.

[0006] In a second aspect, embodiments of the present invention provide a multi-satellite mission planning method, applied to the system described in the first aspect, comprising: Based on the mission request containing multiple specified tasks, the current orbital information and current resource information of each satellite, the ground end allocates at least one execution satellite covering its mission area and meeting its resource requirements for each specified task, and generates a mission planning scheme. When the ground terminal establishes communication with any of the execution satellites, it generates corresponding task instructions based on the mission planning scheme and the planned execution time of each designated task to be executed on the execution satellite, and sends them to the edge core node of the execution satellite. The task instructions include: the container image identifier of the designated task, the container image configuration parameters, and timed triggering information for indicating the planned execution time of the designated task. The planned execution time of each designated task is located within the time period between the current time and the next time the execution satellite establishes communication with the ground terminal. When communication is established between the local satellite and the ground terminal, the mission instructions from the ground terminal are received and parsed, and the timing trigger information is registered to the local timing scheduler. Based on the timed trigger information, when the corresponding planned execution time arrives, a container image for the specified task is created and run to execute the specified task.

[0007] The technical solutions provided by the embodiments of the present invention bring at least the following beneficial effects: This invention utilizes a ground-based mission planning module to calculate and determine the planned execution time for each task, considering the real-time orbital position, resource status, and inherent constraints of each satellite. The planned execution time is encoded as timing trigger information and encapsulated into standardized mission instructions. During the brief communication window between the satellite and the ground, the ground-based cloud core node reliably sends the mission instructions containing this timing trigger information to the edge core node of the target satellite. Upon receiving and parsing the instructions, the edge core node on the satellite registers the timing trigger information within it to its built-in local timing scheduler. When the onboard clock reaches the preset planned execution time, the local timing scheduler triggers, creating and launching the corresponding mission container instance. This ensures that tasks with stringent timing requirements can be launched and executed reliably and on time within the pre-planned optimal or unique time window, even when the satellite-to-ground communication link is unavailable. This overcomes the problem in related technologies where real-time mission triggering and precise timing control are impossible due to the inevitable interruptions and delays in satellite-to-ground communication. Attached Figure Description

[0008] Figure 1 This is a schematic diagram of the architecture of a multi-satellite mission planning system provided in one embodiment of the present invention; Figure 2 This is a schematic diagram of global task planning in one embodiment of the present invention; Figure 3 This is a schematic diagram illustrating an example of global monitoring of task execution in one embodiment of the present invention; Figure 4 This is a schematic diagram illustrating the steps of a multi-satellite mission planning method provided in one embodiment of the present invention. Detailed Implementation

[0009] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0010] The terms "first," "second," etc., used in the specification and claims of this invention are used to distinguish similar objects and are not used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that embodiments of the invention can be implemented in orders other than those illustrated or described herein. Furthermore, in the specification and claims, "and / or" indicates at least one of the connected objects, and the character " / " generally indicates that the preceding and following objects are in an "or" relationship.

[0011] The following description, in conjunction with the accompanying drawings, details a multi-satellite mission planning system and method provided by the present invention through specific embodiments and application scenarios.

[0012] Figure 1 This is a schematic diagram of the architecture of a multi-satellite mission planning system provided in one embodiment of the present invention, as shown below. Figure 1 As shown, the system includes a ground terminal and multiple satellites; the ground terminal includes a mission planning module and a cloud core node; each satellite is equipped with an edge core node, and the edge core node is configured with a local timer scheduler.

[0013] The ground-based terminal is deployed in a ground control center or cloud server, and is mainly responsible for unified reception of tasks, intelligent planning, command generation and distribution, as well as global monitoring and result feedback processing; the satellite-based terminal is distributed on multiple low-orbit satellites, each satellite is equipped with corresponding edge computing and task execution units, and is responsible for receiving ground commands, autonomously executing tasks in orbit, and performing local resource monitoring and task status management.

[0014] Cloud core nodes (such as) Figure 1 The nodes connected to the ground mission planning and scheduling system serve as communication hubs and command distribution channels between the ground and satellite ends. They are based on CloudCore in the Kubernetes framework for functional extension and adaptation, and are used to establish and maintain communication connections with the edge core nodes deployed on each satellite.

[0015] Each satellite participating in the collaborative mission has an edge core node (such as...) deployed on it. Figure 1 The nodes connected to the satellite's onboard planning and scheduling system (the edge core nodes are enhanced based on the KubeEdge framework's EdgeCore and are the control core for receiving, managing, and executing satellite-side tasks) are located on the satellite.

[0016] The mission planning module is used to allocate at least one execution satellite covering its mission area and meeting its resource requirements for each specified mission based on the mission request containing multiple specified missions, the current orbit information and current resource information of each satellite, and to generate a mission planning scheme.

[0017] The mission planning module, deployed at the ground control center, receives and processes mission requests from users. It comprehensively considers the real-time status and future situation of multiple satellites, and through systematic analysis and optimization algorithms, assigns suitable execution satellites to each specified mission, thereby generating a global mission planning scheme. Specifically, the inputs received by the mission planning module include: a mission request containing multiple specified tasks, specifying the details of each task, target area, resource requirements (such as computational load, storage space, energy budget, etc.), and possible time window constraints; current orbital information reported by each satellite, such as its real-time position, velocity, attitude, and orbital parameters; and current resource information for each satellite, covering key operational indicators such as battery level, available computing and storage resources, and equipment temperature.

[0018] In one optional implementation, the task planning module is specifically used for: The current orbit information of each satellite is input into the pre-trained first prediction model to obtain the predicted orbit information of each satellite output by the first prediction model.

[0019] The first prediction model is a data-driven model built on the principles of satellite orbital dynamics. It can extrapolate the satellite's flight trajectory and position changes over a future period based on the satellite's current state, thereby outputting predicted orbit information for each satellite within a specific future time window. This allows the system to know in advance when each satellite will fly over which geographical areas.

[0020] The current resource information of each satellite is input into the pre-trained second prediction model to obtain the predicted resource information of each satellite output by the second prediction model.

[0021] The second prediction model is used to model and predict satellite resource consumption behavior. It comprehensively analyzes factors such as the satellite's historical power consumption data, current load, solar panel irradiation status, and equipment thermal control characteristics to predict the resource status changes of each satellite within the same future time window. It outputs the predicted resource information of each satellite, such as the future battery power decay curve and computing resource occupancy trend.

[0022] Based on the predicted orbit information and the predicted resource information, a predicted resource curve for each satellite within a future time window is determined; the predicted resource curve represents the trend of the resource status of the corresponding satellite changing over time within the future time window.

[0023] The mission planning module integrates and correlates the predicted orbit information with the predicted resource information obtained above. Based on this, a predicted resource curve covering the future time window is constructed for each satellite. The predicted resource curve intuitively represents the dynamic trend of the corresponding satellite's resource status (such as available energy and computing power margin) over time. The predicted resource curve is not merely a static value, but reflects the continuous changes in the satellite's "resource supply capacity" supporting mission operation during the period in which it may perform its next mission.

[0024] Based on the predicted resource curves of each satellite and the resource requirements of each specified task in the mission request, corresponding execution satellites are allocated to each specified task, and the mission planning scheme is generated.

[0025] The mission planning module globally compares and matches the predicted resource curves of all satellites with the resource requirements of each specified mission in the mission request. The decision-making process comprehensively considers: whether the mission's target area is within the coverage of the satellite's predicted orbit; whether the satellite's predicted resource level (read from the predicted resource curve) near the planned mission execution time is sufficient to meet the specified mission's computational, storage, and especially energy consumption requirements; and how to coordinate the distribution of multiple missions across multiple satellites to optimize overall mission completion rate, balance satellite load, and minimize total energy consumption or communication costs—system-level objectives. Through a series of optimization algorithms, the module ultimately allocates one or more suitable execution satellites to each specified mission and determines its approximate execution sequence, thereby generating a mission planning scheme that lays the foundation for subsequent command issuance and on-board execution.

[0026] In one optional implementation, the task planning module is specifically used for: Based on the amount of computational data for each specified task in the task request, the large and small computational tasks included in the task request are determined.

[0027] When making specific task allocation decisions, the task planning module first performs intelligent analysis and classification of the task requests submitted by the user. Specifically, based on the amount of computational data declared, the expected processing complexity, or historical execution characteristics of each specified task in the task request, all tasks are divided into two categories: large-scale computational tasks and small-scale computational tasks. Among them, small-scale computational tasks typically refer to those tasks with relatively light computational loads, short processing times, low continuous occupation of satellite resources, and theoretically capable of being completed independently within a continuous available time window of a satellite, such as extracting specific features from a single remote sensing image, performing lightweight data filtering, or format conversion.

[0028] If the mission request includes at least one small computing task, for each small computing task, based on the predicted resource curves of each satellite and the resource requirements of the small computing task, the executable confidence of the small computing task on each satellite is calculated, and the executable confidence represents the probability that the executing satellite will successfully execute the small computing task within the future time window.

[0029] The mission planning module, for a small computing task to be assigned, traverses each candidate satellite in the constellation and performs the following operations: First, it obtains the predicted resource curve of the satellite for the relevant future time window. Next, it performs spatiotemporal alignment and matching analysis between the resource requirements of the small computing task (e.g., requiring continuous operation for ten minutes, consuming a certain amount of computing resources and power) and the satellite's predicted resource curve. The calculation of the executable confidence score is essentially a multi-dimensional evaluation, considering whether the satellite's predicted available resources continuously meet the mission requirements at the planned execution time, whether the satellite's orbit covers the mission target area, and whether the satellite may have other high-priority mission conflicts or equipment maintenance windows during that time period. Finally, a quantified confidence score is calculated. The confidence score represents the probability that if this small task is assigned to this satellite, the task can be successfully initiated, executed smoothly, and completed within the satellite's future time window. The higher the score, the better the match and the lower the risk of mission failure.

[0030] From the multiple satellites, the satellite with the highest confidence in its feasibility is selected as the execution satellite for the small computing task.

[0031] After calculating the executable confidence score for all candidate satellites for the small computing task, the satellite with the highest executable confidence score is selected and designated as the execution satellite for that small computing task. It is understood that this invention aims to deploy each small task to the satellite platform most likely to successfully execute it under the given conditions, thereby maximizing the overall mission success rate and reliability at the mission level. After all small computing tasks have been allocated through this process, the results will be integrated into the final mission planning scheme.

[0032] In one optional implementation, the task planning module is specifically used for: In cases where the task request includes at least one large computing task, for each large computing task, the large computing task is decomposed into multiple subtasks with execution dependencies.

[0033] After analyzing the task request, the task planning module identifies that it contains at least one large computational task. Its processing strategy differs significantly from that for smaller computational tasks, aiming to overcome the resource and time limitations of a single satellite through multi-satellite collaborative computing. For each identified large computational task, the task planning module first deconstructs it. Based on the computational logic, data processing flow, and input-output dependencies of the large computational task, it is broken down into multiple interrelated subtasks. These subtasks have execution dependencies; for example, the intermediate results produced by some subtasks are necessary inputs for others, or there is a specific execution order among the subtasks.

[0034] Based on the predicted resource curves of each satellite and the resource requirements of the multiple sub-tasks, a corresponding execution satellite is allocated to each sub-task. According to the communication window between each satellite and the ground terminal, the execution order of the multiple sub-tasks on the corresponding execution satellite is determined, thus obtaining the computational pipeline of the large computing task on multiple satellites.

[0035] After decomposing the subtasks, the most suitable execution platform, i.e., a satellite, is identified for each subtask. The decision is based on two main aspects: first, the predicted resource curves of each satellite within the relevant future time windows; and second, the resource requirements of each subtask itself, including estimates of computational intensity, memory usage, expected runtime, and energy consumption. Through matching analysis, the aim is to allocate a satellite to each subtask whose predicted resource curves can consistently and stably meet its requirements during its planned execution period, thus ensuring the subtask's executability.

[0036] However, resource matching alone is insufficient. Due to data transfer and dependencies between subtasks in large-scale computing tasks, the feasibility of inter-satellite or satellite-to-ground data exchange must be considered. Therefore, the mission planning module also needs to deeply integrate predicted information on the communication windows between each satellite and the ground station. Based on these communication windows (i.e., the time periods during which satellites fly over ground stations and can transmit data at high speed), the execution order of all subtasks is arranged. The goal is to construct a computational pipeline spanning multiple satellites and continuous in the time dimension. In this pipeline, after completing its assigned subtask, a preceding satellite can, within its next communication window, download the necessary intermediate results data to the ground or directly transmit it to subsequent satellites (if inter-satellite links are available). Subsequent satellites, upon receiving the required data, initiate and execute subtasks dependent on this data within their allocated time windows.

[0037] Based on the execution satellites allocated to each of the multiple sub-tasks, at least one execution satellite corresponding to the large computing task is determined.

[0038] Finally, through the aforementioned task decomposition, resource matching, and timing orchestration, the task planning module generates a detailed execution blueprint spanning multiple satellites for this large-scale computing task, i.e., a computing pipeline scheme. Based on this, all satellites assigned at least one sub-task collectively constitute the execution satellite set corresponding to complete this large-scale computing task.

[0039] The cloud core node is used to generate corresponding task instructions and send them to the edge core node of the execution satellite, based on the task planning scheme and the planned execution time of each specified task to be executed on the execution satellite, when communication is established with any execution satellite. The task instructions include: the container image identifier of the specified task, the container image configuration parameters, and the timed trigger information for indicating the planned execution time of the specified task. The planned execution time of each specified task is located within the time period between the current time and the next time the execution satellite establishes communication with the ground terminal.

[0040] The cloud core node is deployed at the ground station and enhanced with CloudCore based on the KubeEdge framework. It possesses the ability to establish, maintain, and manage communication connections with edge core nodes of multiple satellites. After the mission planning module generates a global mission planning scheme, the cloud core node monitors the communication status of each executing satellite. Its working logic is as follows: when a usable communication link is detected with a satellite assigned a mission (occurring when the satellite flies over the ground station and enters a preset communication window), the cloud core node initiates the process of generating and issuing mission instructions. Based on the mission planning scheme, it extracts all designated tasks and their attributes that the current satellite needs to execute. For each designated task to be executed, the cloud core node generates a mission instruction based on the planned execution time already determined in the scheme.

[0041] The mission instructions are a structured data packet, the core of which includes: First, a container image identifier specifying the mission. This identifier uniquely points to a specific software image stored in the container image repository, encapsulating all the program code, runtime environment, and dependent libraries required to execute the mission, such as a flood detection algorithm image or a data compression tool image. Second, container image configuration parameters, which are personalized settings for container runtime, including but not limited to environment variables, startup commands, computing resource limits (such as the number of CPU cores and memory size), and data volume mount paths, used to control the mission's execution behavior on the satellite. Third, timed trigger information indicating the planned execution time of the specified mission, specifying when the satellite should automatically start the corresponding containerized mission; its format can be an absolute timestamp (such as a specific moment in Coordinated Universal Time) or an offset relative to the satellite's local clock.

[0042] It is particularly important to note that the planned execution time for each designated task is configured during the planning stage to be within the time period between the current time and the next time the satellite establishes communication with the ground. In other words, the ground can, within the current communication window, pre-send task instructions that need to be executed in the future (i.e., from the end of this communication to the start of the next). Since the satellite is offline for a long period between communication windows, the mechanism of pre-sending and timed automatic restart in this invention is a prerequisite for ensuring that tasks can be executed on time even without real-time ground intervention.

[0043] The edge core node is used to receive and parse the mission instructions from the ground terminal when communication is established between the local satellite and the ground terminal, and to register the timing trigger information to the local timing scheduler.

[0044] The edge core nodes are deployed on the onboard computing platform of each satellite. Based on the KubeEdge framework, EdgeCore has undergone significant functional extensions, particularly integrating autonomous timed scheduling capabilities to cope with the harsh environment of prolonged satellite-to-ground communication disruptions. When the target satellite for a mission enters the ground station's communication coverage area, i.e., enters a pre-defined communication window, the onboard edge core node establishes a connection with the ground-based cloud core node. During this connection, the edge core node receives and processes control commands from the ground. Specifically, the edge core node receives mission command data packets from the cloud core node. These packets encapsulate detailed information about all missions planned by the ground mission planning module for the target satellite. After receiving the data, the edge core node verifies and decapsulates the mission command data packets, extracting structured mission definition information. This includes not only the container image identifier for each specified mission (used to locate the specific software image from local or onboard cache), configuration parameters required for container operation (such as resource limits, environment variables, command parameters, etc.), but also timed trigger information.

[0045] After parsing the timed trigger information, the edge core node registers it with the local time scheduler of the target satellite executing the aforementioned task. The local time scheduler is an independent time monitoring and task triggering service running on the satellite, maintaining a task time registry. The registration process involves binding each task's unique identifier to its planned execution time and storing it in the task time registry, ensuring that the local time scheduler can continuously monitor and know which task needs to be triggered at which future time.

[0046] The edge core node, through the local timer scheduler, creates and runs a container image of the corresponding designated task when the scheduled execution time arrives, based on the timed trigger information, to execute the designated task.

[0047] After the communication connection between the satellite and the ground station ends, the satellite enters a long-term offline autonomous operation state. At this time, the edge core nodes and their local timers take over all task execution management. The local timer runs continuously, constantly comparing the onboard clock with the planned execution time recorded in the task time registry. When the system clock reaches or exceeds the planned execution time of a task, the local timer is activated and sends a trigger signal to the edge core nodes.

[0048] Upon receiving a trigger signal from the local scheduler, the edge core node first locates the corresponding software image file in the local container image repository or cache based on the container image identifier recorded during task registration. Then, combining the container image configuration parameters in the task definition, the node invokes the underlying container runtime (such as a containerization engine) to create a new, isolated container instance. The container instance is granted the necessary computing resources (CPU, memory), access permissions, and configured with the specified runtime environment and startup command. After container creation, the edge core node starts the container image, causing the task application encapsulated within to begin running and execute the specified task.

[0049] Figure 2 This is a schematic diagram of global task planning in one embodiment of the present invention. Please refer to [link / reference]. Figure 2 The user initiates a task request to the access layer on the ground. The access layer first authenticates the task request, and after successful authentication, analyzes it, converts it into a standard task request, and passes it to the task planning module on the server. Based on the received task request containing multiple specified tasks, and combined with the predicted future orbits and resource information of each satellite (predicted resource curve), the task planning module assigns a suitable execution satellite to each task. For small computing tasks, the module calculates its executable confidence on each satellite and selects the optimal satellite; for large computing tasks, it decomposes them into sub-tasks with dependencies, assigns satellites to each sub-task to form a cross-satellite computing pipeline, and finally generates a global task planning scheme.

[0050] Based on the mission planning scheme, the server transmits the planning status (planning in progress) and specific plan to the ground station Master (i.e., the cloud core node). When the cloud core node detects a communication window established with an on-board node of a satellite planned for execution, it generates specific mission instructions based on the planned execution time of the mission to be executed on that satellite (this time is between the current moment and the next communication). The ground station Master then distributes the mission instructions to the corresponding satellite's on-board Edge (i.e., the edge core node).

[0051] After receiving and parsing the instructions, the onboard Edge node registers the defined timed trigger information into its local timer scheduler. When the local clock reaches the scheduled execution time, the local timer scheduler is triggered, and the edge core node then creates and runs the specified container image according to the instructions, thereby executing the corresponding on-orbit computing task.

[0052] In one alternative implementation, each of the satellites is also equipped with an edge data storage module; The edge core node is also used for: The system monitors the execution status of each container image currently running on the local satellite, corresponding to a designated task. Upon detecting the completion or abnormal termination of any designated task, it collects the task status information and task result data for that task. The task status information includes at least the task execution status, reason for termination, resources consumed, and remaining executable time window. The task result data includes files and data summaries generated during the execution of the designated task. The task status information and task result data are stored in the edge data storage module, and when communication is established between the local satellite and the ground terminal, the stored task status information and task result data are sent to the ground terminal. The ground terminal receives the task status information and task result data sent by the first satellite and parses the task status information through the task planning module. If the task status information indicates that the corresponding designated task has been completed, the designated task is determined to be a completed task, and the completed task is removed from the task planning scheme through the task planning module.

[0053] To achieve full lifecycle management of mission execution, ensure data reliability, and support dynamic ground decision-making, this system deploys an edge data storage module on each satellite. This edge data storage module serves as a local, non-volatile storage unit on the satellite, used to persistently store various types of data generated during mission execution.

[0054] After the task container is created and running, the edge core node continuously monitors the execution status of the specified task corresponding to each running container instance on the local satellite, either through an integrated monitoring agent or in collaboration with the status monitoring module of the on-board subsystem. The monitoring is real-time and covers all stages of the task from startup and execution to termination.

[0055] When any designated task is detected to have finished execution (whether normally completed or abnormally stopped for various reasons), the edge core node acquires two types of information: The first type is task status information, which is a structured metadata collection that includes at least: the final execution status of the task (e.g., "success", "failure", "paused", "terminated"); if the task stopped abnormally, the reason for the stop must be recorded (e.g., "battery power below threshold", "computing resources exceeded limit", "process crash", "instruction error", etc.); statistics on various resources actually consumed by the task from start to stop, such as CPU time, peak memory, storage I / O, and most importantly, power consumption; and the remaining executable time window calculated based on the initial time window set for the task (if any). The second type is task result data, which is the substantial output generated by the task application during its operation, including generated result files (e.g., processed images, analysis reports, compressed data packets, etc.) and data summaries that provide a general description of these outputs (e.g., feature vectors, statistical indicators, checksums, etc.).

[0056] After collecting the aforementioned status information and result data, the edge core node will store them uniformly in its local edge data storage module. Even during prolonged periods of complete communication disruption between the satellite and the ground, all mission execution records and outputs can be securely preserved, preventing data loss due to onboard system restarts or accidental malfunctions.

[0057] When the satellite re-enters the communication coverage area of ​​the ground station, that is, when the local satellite and the ground re-establish a communication connection, the edge core node will proactively or after receiving a query command from the ground will package and send the unsynchronized task status information and task result data stored in the edge data storage module to the ground through the established communication link.

[0058] After receiving the aforementioned data packet from a satellite (the first satellite), the ground station first receives and decodes it via the corresponding communication interface. Subsequently, the data is transmitted to the mission planning module for in-depth analysis. The mission planning module analyzes each field in the mission status information to accurately understand the actual execution status of each returned mission. When the mission planning module determines that the mission status information explicitly indicates that a specific mission has been successfully completed, it identifies the mission as "completed." This means that the mission's objective has been achieved, and no further scheduling or execution is required. Therefore, the mission planning module proactively removes the completed mission entry from the currently maintained global or satellite-specific mission planning scheme. Thus, subsequent planning work is always based on the latest set of incomplete missions, avoiding ineffective resource planning and duplicate command issuance, thereby significantly improving the management efficiency and timeliness of the entire multi-satellite mission planning system. Simultaneously, the results of successfully completed missions are stored in the global database for subsequent data application and analysis.

[0059] In an optional implementation, the task planning module is further configured to: determine that the designated task is an incomplete task when the task status information indicates that the designated task has stopped abnormally; determine whether the first satellite can resume execution of the incomplete task within the remaining executable time window based on the reason for stopping, consumed resources, and remaining executable time window in the task status information; if it is determined that the first satellite cannot resume execution of the incomplete task within the remaining executable time window, select a second satellite from the plurality of satellites that covers the task area of ​​the incomplete task and meets the resource requirements of the incomplete task, and update the task planning scheme accordingly; determine at least one candidate time window that the second satellite can cover the task area of ​​the incomplete task; select a time window within the maximum delay tolerance time from the at least one candidate time window as the planned execution time of the incomplete task based on the maximum delay tolerance time of the incomplete task; and, when the cloud core node establishes communication with the ground end and the second satellite, generate a corresponding migration task instruction based on the updated task planning scheme and the planned execution time of the incomplete task, and send the migration task instruction and the task result data of the incomplete task to the edge core node of the second execution satellite.

[0060] When the mission planning module receives mission status information from the first satellite (the original mission execution satellite) and parses it to indicate that the corresponding designated mission has abnormally stopped (rather than completed normally), it first marks the designated mission as an "incomplete mission" based on the mission status information. Then, the mission planning module assesses the possibility of recovering the incomplete mission on the first satellite. The input for this assessment consists of several key fields contained in the mission status information: the specific reason for the stop, the amount of resources consumed by the mission, and the remaining executable time window calculated based on the original plan window. The module analyzes and judges based on this information: for example, if the stop is due to temporary power shortage but the satellite is about to enter a sunlight-received area for charging, and the remaining time window is long enough, it may be considered recoverable; if the stop is due to permanent hardware failure or the remaining time window is extremely short, it is considered unrecoverable.

[0061] After evaluation, if it is determined that the first satellite cannot resume the unfinished mission within the remaining executable time window, the mission planning module will reselect a second satellite from among the other satellites in the constellation that meet the criteria. The selection criteria are similar to the initial planning but more targeted: the second satellite must be able to cover the target area required by the unfinished mission (i.e., its orbit must pass through the area), and its predicted resource capabilities (based on the latest predicted resource curve) must meet the resource requirements of the remaining part of the unfinished mission.

[0062] After identifying the second candidate satellite, a new execution time is planned for it. First, all time windows within a future period that the second satellite can cover the target area of ​​the unfinished task are calculated as candidate time windows. Then, the maximum tolerable delay time for the unfinished task is determined. This is defined as the maximum allowed delay time from the original planned time, determined by the urgency of the task itself. The mission planning module selects a suitable window from all candidate time windows that falls within the executable range of the second satellite and the maximum tolerable delay time range of the unfinished task, and sets this window as the new planned execution time for that unfinished task.

[0063] When the ground station establishes a new communication connection with the selected second satellite, the cloud core node will generate a migration task instruction based on this updated scheme. This migration task instruction not only includes information such as the container image identifier, configuration parameters, and newly determined planned execution time required to restart the incomplete task, but also encapsulates and distributes the "task result data" (such as processed intermediate data) already transmitted back from the first satellite. In this way, the edge core node of the second satellite, upon receiving the instruction, can continue executing the task from where it was interrupted by the first satellite, rather than starting from scratch, thereby maximizing the conservation of valuable onboard computing resources and time, and achieving seamless task continuity. Therefore, this invention enhances the resilience of the entire multi-satellite system to sudden failures and resource fluctuations.

[0064] In one alternative implementation, the edge core node of the second execution satellite is specifically used for: The system receives and parses the migration task instruction and the task result data from the ground terminal. The migration task instruction includes the container image identifier of the incomplete task, container image configuration parameters, and timed trigger information indicating the planned execution time of the incomplete task.

[0065] When the second execution satellite enters the communication window with the ground, its onboard edge core node first receives and parses the migration mission instructions and mission result data from the ground. In other words, the edge core node receives a data packet specifically constructed by the ground cloud core node for this mission migration, including: first, the migration mission instructions, which contain the container image identifier of the incomplete mission (used to locate the specific software image on the satellite or obtain it from the ground), container image configuration parameters, and timing trigger information corresponding to the planned execution time on the second satellite, which is recalculated and determined by the ground mission planning module; second, the mission result data transmitted back from the first satellite and forwarded by the ground, that is, the intermediate output or partial results that the mission has been executed and generated but not completed on the first satellite.

[0066] The timed trigger information is registered to the local timer scheduler, and the task result data of the unfinished tasks is stored in the edge data storage module.

[0067] On one hand, the edge core node submits the parsed new planned execution time (timed trigger information) to the local time scheduler for registration. The local time scheduler records this incomplete task and its timed trigger information, and monitors the countdown independently of the ground. Even if communication with the ground is lost again, the task can be automatically awakened at the scheduled time. On the other hand, the edge core node writes the task result data from the first satellite, which accompanies the issuance of instructions, into its local edge data storage module.

[0068] When the scheduled execution time of the unfinished task arrives, the local timer scheduler creates and runs a container image of the unfinished task and loads the task result data of the unfinished task from the edge data storage module to continue the execution of the unfinished task from the location where the first satellite interrupted execution.

[0069] When the onboard local clock reaches the registered scheduled time, the local timer scheduler is triggered, issuing execution instructions to the edge core node. Based on the container image identifier and configuration parameters specified in the migration instructions, the edge core node starts the containerized runtime, creating and running a new task container instance. Simultaneously with or during the initialization phase of this container, the edge core node instructs the container to load previously stored task result data from a specific location in the edge data storage module. In this way, the newly launched task application obtains the complete state before the task was interrupted or the intermediate data already processed, enabling it to directly continue computation, analysis, or processing at its logical breakpoint.

[0070] In one optional implementation, the cloud core node is specifically used for: Based on the at least one execution satellite allocated to each specified task in the mission planning scheme, and the planned execution time of each specified task, a corresponding custom resource object is constructed. The custom resource object contains at least one task entry, and each task entry is used to define the execution parameters of a specified task. The execution parameters include at least the container image identifier, container image configuration parameters, planned execution time, and resource requirements corresponding to the specified task. The custom resource object is encapsulated in a configuration item to generate the task instruction. When the ground end establishes communication with any execution satellite, the task instruction is sent to the edge core node of the execution satellite. Based on the task planning scheme output by the task planning module, the cloud core node constructs corresponding custom resource objects for each specified task, including at least one execution satellite and a specific planned execution time. A custom resource object is essentially a structured data description unit containing at least one task entry. Each task entry corresponds to a specified task to be executed and fully defines the execution parameters of that task, including at least the container image identifier, container image configuration parameters, planned execution time, and resource requirements. In this way, the execution attributes of each task are recorded in a standardized and structured manner, facilitating unified parsing and processing by the system. Subsequently, the cloud core node further encapsulates this custom resource object within configuration items, generating a transmittable task instruction data packet. When the ground subsystem establishes a communication connection with any execution satellite, the cloud core node reliably sends the encapsulated task instructions to the edge core nodes deployed on the target satellite through this connection channel, thus completing the task instruction transmission process from the ground to the satellite.

[0071] The edge core node is specifically used for: The system receives and parses the task instruction to identify the custom resource object in the configuration item; it converts at least one task entry defined in the custom resource object into an internal schedulable object and stores it in the local execution queue; it listens to the local clock through the local timer scheduler, and when the local clock reaches the planned execution time recorded by any internal schedulable object, it retrieves the internal schedulable object from the execution queue, and creates and runs the corresponding container instance according to the container image identifier and container image configuration parameters recorded in the internal schedulable object to execute the corresponding specified task.

[0072] At the satellite end, the edge core node is responsible for parsing and scheduling the received task instructions. The specific process is as follows: After establishing communication between the local satellite and the ground station and receiving the task instructions, the edge core node first parses the instructions, extracting the custom resource objects encapsulated within the configuration items. Next, the edge core node converts each task entry defined in the custom resource object into an internally schedulable object that can be recognized and processed by the satellite's internal task scheduling system. These internally schedulable objects carry task execution information consistent with the original task entries and are stored in the satellite's local execution queue, awaiting triggering. Simultaneously, the local timer scheduler integrated on the satellite begins continuous operation, monitoring the satellite's local clock in real time. When the local clock reaches the planned execution time recorded in any internally schedulable object, the local timer scheduler automatically extracts the corresponding internally schedulable object from the execution queue. Subsequently, based on the container image identifier and container image configuration parameters recorded in the object, the local timer scheduler creates a corresponding container instance in the satellite's local container runtime environment and starts the execution of the container instance, thereby accurately and automatically executing the corresponding specified task.

[0073] Figure 3 This is a schematic diagram illustrating a global monitoring example of task execution in one embodiment of the present invention. Please refer to [link / reference]. Figure 3 Suppose a user submits an emergency flood monitoring task request through a ground control center, requesting remote sensing imagery acquisition and real-time on-orbit flood inundation detection and analysis for regions A and B, respectively. This task request includes two specified tasks: Task 1 (corresponding to region A) and Task 2 (corresponding to region B). Each task has strict execution time window constraints (it must be completed when the satellite passes over the target area), and requires the use of containerized flood detection algorithm images, thus placing certain demands on computing resources and storage.

[0074] After receiving the mission request, the ground mission planning module, combining the current orbit information and resource status reported by each satellite, calculates the predicted orbit information and predicted resource curves for Satellite 1, Satellite 2, and Satellite 3 for the next few hours using its built-in orbit prediction model and resource prediction model. Analysis determines that Satellite 1 will fly over Region A around 10:00 AM, and its prediction computing resources and power are sufficient within the corresponding time window to meet the execution requirements of Mission 1; Satellite 2 will fly over Region B around 10:30 AM, and its predicted resources meet the requirements at the initial stage of the mission. Based on this, the mission planning module generates an initial mission planning scheme: assigning Mission 1 to Satellite 1, with a planned execution time of 10:00 AM; and assigning Mission 2 to Satellite 2, with a planned execution time of 10:30 AM.

[0075] When Satellite 1 enters the communication window with the ground station at 9:50, the cloud core node generates a task instruction for Satellite 1 according to the aforementioned planning scheme. The task instruction is encapsulated as a custom resource object, containing the container image identifier for Task 1 (e.g., "flood-detection-v1.0"), configuration parameters (e.g., CPU=2 cores, memory=2GB), and timed trigger information (planned execution time=10:00). The task instruction is sent to the edge core node deployed on Satellite 1 via the communication link. After receiving and parsing the instruction, the edge core node registers the timed trigger information with its local timer scheduler and stores the task definition in the execution queue. Subsequently, Satellite 1 leaves the communication range and enters an offline autonomous state.

[0076] Similarly, when Satellite 2 enters the communication window, the ground terminal sends the instructions for Mission 2 to Satellite 2, and its edge core nodes also complete the local registration of the timed tasks.

[0077] At 10:00 AM, Satellite 1's local timer detected the arrival of the scheduled time. The edge core node retrieved the internally schedulable object for Task 1 from the execution queue, and created and started the corresponding container instance based on the container image identifier and configuration parameters recorded therein. The water body identification algorithm encapsulated within the container began running, and Satellite 1 simultaneously controlled the optical payload to photograph Area A. The acquired image data was transmitted to the container for processing in real time. During processing, the edge core node continuously monitored the task status and recorded resource consumption (e.g., peak CPU utilization of approximately 70% and memory usage of approximately 1GB). Task 1 was successfully completed at 10:05 AM, and the generated flood detection results (e.g., a binary map of the inundation area) and execution log were saved to Satellite 1's local edge data storage module.

[0078] At approximately 10:15, Satellite 1 re-entered the ground communication range. The edge core node automatically packaged and sent the task status information (status as "Completed", resource consumption statistics, etc.) and task result data (processed images and detection results) stored in the local edge data storage module to the ground terminal. Upon receiving the data, the ground mission planning module parsed the status information, confirmed that Task 1 had been successfully completed, removed it from the current mission planning scheme, and stored the result data in the business database for user use. At this point, the mission execution process for Satellite 1 ended.

[0079] At 10:30 AM, Satellite 2's local timer triggered Task 2 as scheduled. The edge core node started the corresponding flood detection container and began capturing and processing images of Area B in real time. However, due to the relatively limited onboard computing power of Satellite 2 and the large amount of data to be processed, the task execution progress was slow. At approximately 10:45 AM, the onboard energy monitoring module detected that the battery level had dropped to a preset threshold (20%). To prevent system anomalies caused by battery depletion, the edge core node proactively suspended the container process corresponding to Task 2 according to a preset strategy. At the same time, it immediately collected and saved the intermediate state of the task: including partially processed image data, intermediate results generated by the algorithm, the amount of resources consumed (CPU time, memory), the reason for stopping ("battery level below the threshold"), and the remaining executable time window calculated based on the original time window.

[0080] When Satellite 2 briefly enters the communication window at 11:00, the edge core node sends the aforementioned mission status information and the saved mission result data (i.e., partial processing results) to the ground. After receiving and parsing the data, the ground mission planning module confirms that Mission 2 has abnormally stopped due to resource constraints and is marked as "unfinished mission".

[0081] The mission planning module evaluates the mission status information (reason for termination, consumed resources, and remaining executable time window) reported by Satellite 2. It determines that Satellite 2 cannot resume mission 2 within the remaining time window due to insufficient power and impending entry into the shadow zone. Other satellites with sufficient resources and coverage for region B are selected from the constellation. Based on predictions, Satellite 3 will fly over region B that afternoon, and its predicted resource curve shows sufficient computing resources and power for the corresponding time period. Satellite 3 is therefore selected as the second satellite to take over the mission.

[0082] The mission planning module further calculates candidate time windows (e.g., 14:20-14:40) for its coverage area B based on the predicted orbit of satellite 3, and combines this with the maximum delay tolerance time for mission 2 (the user allows the mission to be completed no later than the same day), selecting 14:30 as the new planned execution time. Subsequently, the global mission planning scheme is updated, and mission 2 is reassigned to satellite 3, with a planned execution time of 14:30.

[0083] That afternoon, Satellite 3 entered the communication window. Based on the updated plan, the cloud core node generated a migration task instruction and sent it to Satellite 3. This instruction included the original container image identifier and configuration parameters from Task 2, as well as new timing trigger information (14:30), and also the task result data previously transmitted back from Satellite 2 (i.e., some processed intermediate data). Upon receiving the instruction, the edge core node of Satellite 3 registered the new timing information with the local scheduler and stored the migrated intermediate data in its local edge data storage module.

[0084] At 14:30, the local timer scheduler on Satellite 3 triggered the execution of Task 2. The edge core node created and started the flood detection container, guiding it to load intermediate data from Satellite 2 from its local edge data storage module. Based on this intermediate data, the algorithm within the container resumed execution from where it had been interrupted on Satellite 2, completing the analysis of the remaining image data. Ultimately, Task 2 was successfully executed on Satellite 3, and the complete flood detection results were saved.

[0085] As Satellite 3 passes overhead in the evening, its edge core node transmits the final mission status information ("Completed") and all result data of Mission 2 to the ground. Upon receiving this data, the mission planning module marks Mission 2 as completed and removes it from the plan, thus completing the entire flood monitoring mission.

[0086] Figure 4 This is a schematic diagram illustrating the steps of a multi-satellite mission planning method according to an embodiment of the present invention. Please refer to [link / reference]. Figure 4 Applied to the systems described above; including: Step S11: The ground terminal, based on the mission request containing multiple specified tasks, the current orbit information and current resource information of each satellite, allocates at least one execution satellite covering its mission area and meeting its resource requirements for each specified task, and generates a mission planning scheme.

[0087] The system receives and processes task requests from users, comprehensively considers the real-time status and future situation of multiple satellites, and uses systematic analysis and optimization algorithms to assign suitable execution satellites to each specified task, thereby generating a global task planning scheme. Specifically, the received inputs include: a task request containing multiple specified tasks, which specifies the details of each task, target area, resource requirements (such as computational load, storage space, energy budget, etc.), and possible time window constraints; current orbital information reported by each satellite, such as its real-time position, velocity, attitude, and orbital parameters; and current resource information of each satellite, covering key operational indicators such as battery level, available computing and storage resources, and equipment temperature.

[0088] In step S12, when the ground terminal establishes communication with any execution satellite, it generates corresponding task instructions based on the task planning scheme and the planned execution time of each specified task to be executed on the execution satellite, and sends them to the edge core node of the execution satellite. The task instructions include: the container image identifier of the specified task, the container image configuration parameters, and the timed trigger information for indicating the planned execution time of the specified task. The planned execution time of each specified task is located within the time period between the current time and the next time the execution satellite establishes communication with the ground terminal.

[0089] The system monitors the communication status of each satellite. Upon detecting a usable communication link with a satellite assigned a task (occurring when the satellite flies over the ground station and enters a pre-defined communication window), it extracts all designated tasks and their attributes that the satellite needs to perform, based on the mission planning scheme. For each designated task to be executed, the cloud core node generates a mission instruction based on the planned execution time already determined in the scheme.

[0090] The mission instructions are a structured data packet, the core of which includes: First, a container image identifier specifying the mission. This identifier uniquely points to a specific software image stored in the container image repository, encapsulating all the program code, runtime environment, and dependent libraries required to execute the mission, such as a flood detection algorithm image or a data compression tool image. Second, container image configuration parameters, which are personalized settings for container runtime, including but not limited to environment variables, startup commands, computing resource limits (such as the number of CPU cores and memory size), and data volume mount paths, used to control the mission's execution behavior on the satellite. Third, timed trigger information indicating the planned execution time of the specified mission, specifying when the satellite should automatically start the corresponding containerized mission; its format can be an absolute timestamp (such as a specific moment in Coordinated Universal Time) or an offset relative to the satellite's local clock.

[0091] It is particularly important to note that the planned execution time for each designated task is configured during the planning stage to be within the time period between the current time and the next time the satellite establishes communication with the ground. In other words, the ground can, within the current communication window, pre-send task instructions that need to be executed in the future (i.e., from the end of this communication to the start of the next). Since the satellite is offline for a long period between communication windows, the mechanism of pre-sending and timed automatic restart in this invention is a prerequisite for ensuring that tasks can be executed on time even without real-time ground intervention.

[0092] Step S13: When communication is established between the local satellite and the ground terminal, the mission instructions from the ground terminal are received and parsed, and the timing trigger information is registered to the local timing scheduler.

[0093] When the target satellite for the mission enters the ground station's communication coverage area, i.e., enters the preset communication window, the satellite establishes a connection with the ground-based cloud core node. During this connection, the edge core node receives and processes control commands from the ground. Specifically, the edge core node receives mission command data packets issued by the cloud core node. These packets encapsulate detailed information about all missions planned by the ground mission planning module for the target satellite. After receiving the data, the edge core node verifies and decapsulates the mission command data packets, extracting the structured mission definition information. This includes not only the container image identifier corresponding to each specified mission (used to locate the specific software image from local or on-board cache), the configuration parameters required for container operation (such as resource limits, environment variables, command parameters, etc.), but also timed trigger information.

[0094] After parsing the timed trigger information, it is registered with the local time scheduler of the target satellite executing the task. The local time scheduler is an independent time monitoring and task triggering service running on the satellite, maintaining a task time registry. The registration process involves binding the unique identifier of each task to its planned execution time and storing it in the task time registry, ensuring that the local time scheduler can continuously monitor and know which task needs to be triggered at which point in the future.

[0095] Step S14: Based on the timed trigger information, when the corresponding planned execution time arrives, create and run the container image of the specified task to execute the specified task.

[0096] After communication between the satellite and the ground station ends, the satellite enters a long-term offline autonomous operation state. During this time, the onboard clock is continuously compared with the planned execution time recorded in the mission time registry. When the system clock reaches or exceeds the planned execution time of a mission, the corresponding software image file is located in the local container image repository or cache based on the container image identifier recorded during mission registration. Subsequently, combined with the container image configuration parameters in the mission definition, the node invokes the underlying container runtime (such as a containerization engine) to create a brand-new, isolated container instance. The container instance is granted the necessary computing resources (CPU, memory), access permissions, and configured with the specified runtime environment and startup command. After the container is created, the edge core node starts the container image, causing the task application encapsulated within to begin running, thereby executing the specified task.

[0097] In one alternative implementation, it further includes: Step S21: Monitor the execution status of the specified task corresponding to each container image currently running on the local satellite. If any specified task is detected to have ended or stopped abnormally, collect the task status information and task result data of the specified task. The task status information includes at least the task execution status, the reason for stopping, the resources consumed, and the remaining executable time window. The task result data includes the files and data digests generated during the execution of the specified task.

[0098] After the task container is created and running, the execution status of the specified task corresponding to each running container instance on the local satellite is continuously monitored. The monitoring is real-time and covers all stages of the task from startup, execution to termination.

[0099] When any designated task is detected to have finished execution (whether normally completed or abnormally stopped for various reasons), two types of information are acquired: The first type is task status information, which is a structured metadata collection that includes at least: the final execution status of the task (e.g., "success", "failure", "paused", "terminated"); if the task stopped abnormally, the reason for the stop must be recorded (e.g., "battery power below threshold", "computing resources exceeded limit", "process crash", "instruction error", etc.); statistics on various resources actually consumed by the task from start to stop, such as CPU time, peak memory usage, storage I / O, and most importantly, power consumption; and the remaining executable time window calculated based on the initial time window set for the task (if any). The second type is task result data, which is the substantial output generated by the task application during its operation, including generated result files (e.g., processed images, analysis reports, compressed data packets, etc.) and data summaries that provide a general description of these outputs (e.g., feature vectors, statistical indicators, checksums, etc.).

[0100] Step S22: Store the mission status information and mission result data in the edge data storage module, and when communication is established between the local satellite and the ground terminal, send the stored mission status information and mission result data to the ground terminal.

[0101] When the satellite re-enters the communication coverage area of ​​the ground station, that is, when the local satellite and the ground re-establish a communication connection, it will proactively or after receiving a ground query instruction, package and send the unsynchronized mission status information and mission result data stored in the edge data storage module to the ground station through the established communication link.

[0102] Step S23: The ground terminal receives the mission status information and mission result data sent by the first satellite, and parses the mission status information through the mission planning module.

[0103] After receiving the aforementioned data packet from a satellite (the first satellite), the ground station first receives and decodes it via the corresponding communication interface. Subsequently, the data is transmitted to the mission planning module for in-depth analysis. The mission planning module analyzes each field in the mission status information to accurately understand the actual execution status of each transmitted task.

[0104] Step S24: If the task status information indicates that the corresponding designated task has been completed, determine that the designated task is a completed task, and remove the completed task from the task planning scheme through the task planning module.

[0105] When the parsed task status information explicitly indicates that a specific task has been successfully completed, the task can be designated as a "completed task." This means the task's objective has been achieved, and no further scheduling or execution is required. Therefore, the task planning module will proactively remove the completed task entry from the currently maintained global or satellite-specific task planning schemes. Consequently, subsequent planning is always based on the latest set of incomplete tasks, avoiding ineffective resource planning and duplicate command issuance, thus significantly improving the management efficiency and timeliness of the entire multi-satellite task planning system. Simultaneously, the results of successfully completed tasks are stored in the global database for subsequent data application and analysis.

[0106] Although preferred embodiments of the present invention have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of the embodiments of the present invention.

[0107] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or terminal device that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or terminal device. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or terminal device that includes said element.

[0108] The embodiments of the present invention have been described above with reference to the accompanying drawings. However, the present invention is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of the present invention without departing from the spirit and scope of the claims. All of these forms are within the protection scope of the present invention.

Claims

1. A multi-satellite mission planning system, characterized by, The system comprises a ground terminal and a plurality of satellites; the ground terminal comprises a task planning module and a cloud core node; each satellite is deployed with an edge core node, and the edge core node is configured with a local timing scheduler; The task planning module is configured to allocate at least one execution satellite for each specified task according to a task request containing a plurality of specified tasks, current orbit information and current resource information of each satellite, generate a task planning scheme, and the execution satellite covers the task area of the specified task and meets the resource requirement of the specified task; The cloud core node is configured to generate a corresponding task instruction according to the task planning scheme and the planned execution time of each specified task to be executed on the execution satellite when communication with the execution satellite is established, and send the task instruction to the edge core node of the execution satellite; The task instruction comprises a container image identifier of the specified task, a container image configuration parameter, and timing trigger information for indicating the planned execution time of the specified task; the planned execution time of each specified task is located in a time period between the current time and the next time when the execution satellite establishes communication with the ground terminal; The edge core node is configured to receive and analyze the task instruction from the ground terminal when the local satellite establishes communication with the ground terminal, and register the timing trigger information to the local timing scheduler; The edge core node creates and runs the container image of the corresponding specified task to execute the specified task according to the timing trigger information through the local timing scheduler when the corresponding planned execution time arrives.

2. The system of claim 1, wherein, Each satellite is also deployed with an edge data storage module; The edge core node is further configured to: monitor the execution state of each container image corresponding to the specified task currently running on the local satellite, collect the task state information and task result data of the specified task when any specified task execution ends or abnormally stops; the task state information at least comprises the task execution state, the stopping reason, the consumed resources and the remaining executable time window; the task result data comprises the file and data summary generated in the execution process of the specified task; store the task state information and the task result data to the edge data storage module, and send the stored task state information and the task result data to the ground terminal when the local satellite establishes communication with the ground terminal; The ground terminal receives the task state information and the task result data sent by the first satellite, and analyzes the task state information through the task planning module; when the task state information indicates that the corresponding specified task is executed, the specified task is determined as a completed task, and the completed task is removed from the task planning scheme through the task planning module.

3. The system of claim 2, wherein, The task planning module is further configured to: when the task state information indicates that the corresponding specified task is abnormally stopped, the specified task is determined as an uncompleted task; Based on the reason for stopping, the resources consumed, and the remaining executable time window in the task status information, determine whether the first satellite can resume executing the unfinished task within the remaining executable time window; If it is determined that the first satellite cannot resume the execution of the unfinished task within the remaining executable time window, a second satellite that covers the task area of ​​the unfinished task and meets the resource requirements of the unfinished task is selected from the plurality of satellites, and the task planning scheme is updated accordingly. Determine at least one candidate time window in which the second satellite can cover the mission area of ​​the unfinished mission; Based on the maximum delay tolerance time for the unfinished task, select a time window within the range of the maximum delay tolerance time from the at least one candidate time window as the planned execution time for the unfinished task; When the cloud core node establishes communication with the ground terminal and the second satellite, it generates a corresponding migration task instruction based on the updated task planning scheme and the planned execution time of the unfinished task, and sends the migration task instruction and the task result data of the unfinished task to the edge core node of the second execution satellite.

4. The system of claim 3, wherein, The edge core node of the second execution satellite is specifically used for: The system receives and parses the migration task instruction and the task result data from the ground terminal. The migration task instruction includes the container image identifier of the incomplete task, container image configuration parameters, and timed triggering information for indicating the planned execution time of the incomplete task. The timed trigger information is registered to the local time scheduler, and the task result data of the unfinished tasks is stored in the edge data storage module; When the scheduled execution time of the unfinished task arrives, the local timer scheduler creates and runs a container image of the unfinished task and loads the task result data of the unfinished task from the edge data storage module to continue the execution of the unfinished task from the location where the first satellite interrupted execution.

5. The system of claim 1, wherein, The task planning module is specifically used for: The current orbit information of each satellite is input into the pre-trained first prediction model to obtain the predicted orbit information of each satellite output by the first prediction model. The current resource information of each satellite is input into the pre-trained second prediction model to obtain the predicted resource information of each satellite output by the second prediction model. Based on the predicted orbit information and the predicted resource information, a predicted resource curve for each satellite within a future time window is determined; the predicted resource curve represents the trend of the resource status of the corresponding satellite changing over time within the future time window. Based on the predicted resource curves of each satellite and the resource requirements of each specified task in the mission request, corresponding execution satellites are allocated to each specified task, and the mission planning scheme is generated.

6. The system of claim 5, wherein, The task planning module is specifically used for: Based on the amount of computational data for each specified task in the task request, determine the large and small computational tasks included in the task request. In cases where the mission request includes at least one small computing task, for each small computing task, based on the predicted resource curves of each satellite and the resource requirements of the small computing task, the executable confidence of the small computing task on each satellite is calculated, and the executable confidence represents the probability that the executing satellite will successfully execute the small computing task within the future time window. From the multiple satellites, the satellite with the highest confidence in its feasibility is selected as the execution satellite for the small computing task.

7. The system of claim 6, wherein, The task planning module is specifically used for: In the case where the task request includes at least one large computing task, for each large computing task, the large computing task is decomposed into multiple subtasks with execution dependencies. Based on the predicted resource curves of each satellite and the resource requirements of the multiple sub-tasks, a corresponding execution satellite is allocated to each sub-task. According to the communication window between each satellite and the ground terminal, the execution order of the multiple sub-tasks on the corresponding execution satellite is determined, and the computing pipeline of the large computing task on multiple satellites is obtained. Based on the execution satellites allocated to each of the multiple sub-tasks, at least one execution satellite corresponding to the large computing task is determined.

8. The system of claim 1, wherein, The cloud core node is specifically used for: Based on the at least one execution satellite allocated to each specified task in the mission planning scheme, and the planned execution time of each specified task, a corresponding custom resource object is constructed; the custom resource object contains at least one task entry, and each task entry is used to define the execution parameters of a specified task. The execution parameters include at least the container image identifier, container image configuration parameters, planned execution time, and resource requirements corresponding to the specified task. The custom resource object is encapsulated in a configuration item to generate the task instruction. When the ground terminal establishes communication with any execution satellite, the task instruction is sent to the edge core node of the execution satellite. The edge core node is specifically used for: Receive and parse the task instruction to determine the custom resource object in the configuration item; At least one task entry defined in the custom resource object is converted into an internal schedulable object and stored in the local execution queue; The local timer monitors the local clock, and when the local clock reaches the planned execution time recorded by any internally scheduled object, it extracts the internally scheduled object from the queue to be executed, and creates and runs the corresponding container instance according to the container image identifier and container image configuration parameters recorded in the internally scheduled object to execute the corresponding specified task.

9. A multi-satellite mission planning method, characterized by, Applied to the system as described in any one of claims 1-8; comprising: Based on the mission request containing multiple specified tasks, the current orbital information and current resource information of each satellite, the ground end allocates at least one execution satellite covering its mission area and meeting its resource requirements for each specified task, and generates a mission planning scheme. When the ground terminal establishes communication with any of the execution satellites, it generates corresponding task instructions based on the mission planning scheme and the planned execution time of each designated task to be executed on the execution satellite, and sends them to the edge core node of the execution satellite. The task instructions include: the container image identifier of the designated task, the container image configuration parameters, and timed triggering information for indicating the planned execution time of the designated task. The planned execution time of each designated task is located within the time period between the current time and the next time the execution satellite establishes communication with the ground terminal. When communication is established between the local satellite and the ground terminal, the mission instructions from the ground terminal are received and parsed, and the timing trigger information is registered to the local timing scheduler. Based on the timed trigger information, when the corresponding planned execution time arrives, a container image for the specified task is created and run to execute the specified task.

10. The method of claim 9, wherein, Also includes: Monitor the execution status of each container image currently running on the local satellite corresponding to a specified task. If any specified task is detected to have ended or stopped abnormally, collect the task status information and task result data of that specified task. The task status information includes at least the task execution status, the reason for stopping, the resources consumed, and the remaining executable time window. The task result data includes the files and data summaries generated during the execution of the specified task. The task status information and the task result data are stored in the edge data storage module, and when communication is established between the local satellite and the ground terminal, the stored task status information and the task result data are sent to the ground terminal. The ground terminal receives the mission status information and mission result data sent by the first satellite, and parses the mission status information through the mission planning module; If the task status information indicates that the corresponding designated task has been completed, the designated task is determined to be a completed task, and the completed task is removed from the task planning scheme by the task planning module.

Images