A Distributed Satellite Mission Planning System

Abstract

The distributed satellite task planning system of the present invention is characterized by: being used for multi-satellite collaborative computing of distributed computing clusters, including dividing the global space into four zones, each zone performing independent task planning; all satellite nodes in the zone deploy a task planning application system to provide users with access request collection and task scheduling result feedback services. The present invention can achieve dynamic scalability of system cluster scale and task scheduling, ensure data consistency and high availability of services, and support efficient and reliable task scheduling on distributed satellite clusters.

Description

Technical Field

[0001] The present invention relates to the field of aerospace technology, and in particular to a distributed satellite mission planning system. Background Art

[0002] In recent years, satellite Internet technology has developed rapidly. Countries have promoted satellite Internet construction to a national strategy. my country has included satellite Internet in the scope of new infrastructure. Satellite Internet may be composed of thousands of satellites, which form a distributed system. How to perform efficient and reliable task scheduling on distributed satellite clusters has become a problem that needs to be solved urgently in satellite Internet.

[0003] In the satellite cluster built by satellite interconnection, the distributed task scheduling strategy is the key to achieve the reasonable planning and scheduling of tasks in multi-satellite and multi-task application scenarios under complex constraints. The task scheduling strategy based on the distributed framework is a task scheduling solution provided by various distributed cluster management systems.

[0004] Simply put, the space-based Internet is a mobile distributed Internet consisting of a group of satellites that communicate through intersatellite links and work together to complete tasks. Since the space-based Internet is a distributed satellite network, information is replicated and transmitted in the satellite network, which brings up the problem of distributed consistency. The consistency problem has a long history of research in computer science and is an important foundation in the distributed field. The existing terrestrial Internet distributed consistency algorithm is mainly used to maintain the consistency of each copy in the processing of data replication problems, and is only applicable to high-throughput and low-latency networks. Due to the characteristics of high-speed satellite movement, intersatellite links are intermittent, bandwidth is limited, and the delay time of communication between satellites is long. This does not meet the low-latency requirements of the current consistency protocol, so the terrestrial Internet distributed consistency algorithm cannot be fully applied to satellite networks. Summary of the invention

[0005] In order to solve the above-mentioned deficiencies in the prior art, the present invention proposes a distributed satellite mission planning system.

[0006] In order to achieve the above-mentioned purpose, the present invention proposes a distributed satellite mission planning system for multi-satellite collaborative computing of distributed computing clusters, including dividing the global space into four zones, each zone performing independent mission planning; all satellite nodes in the zone deploy a mission planning application system to provide users with access request collection and task scheduling result feedback services.

[0007] Furthermore, the mission planning transport layer constellation is divided into four sectors according to the 0° and 180° longitudes and the equator.

[0008] Moreover, for task planning, each partition has one and only one core node, and the others are ordinary nodes; all nodes can receive access request information from users and converge to the core node in the partition; the composition of satellite nodes in each partition is dynamically changed, and the roles of core nodes and ordinary nodes can be switched.

[0009] Moreover, the Raft consensus algorithm is used to elect core nodes. The core nodes evaluate the controlled beam resources and user requests according to the trigger mechanism, split the tasks as needed, form several independent subtasks, publish them to the distributed computing cluster for multi-satellite collaborative computing and collect the results, and finally output the beam scheduling results.

[0010] Moreover, the task planning application system includes a system management module, a task collection module, a task aggregation module, a visible resource module and a task coordination module. Ordinary nodes only run the system management module and the task collection module, and core nodes run all modules.

[0011] Furthermore, the system management module receives the partition information sent by the application auxiliary support node.

[0012] Moreover, the task collection module maintains a task queue. When a node receives a task library update message sent by the application auxiliary support software, it actively queries the task library, updates the task queue, and sends the task information to the task aggregation module of the core node in the partition.

[0013] Furthermore, the task aggregation module is used to send notifications to the visible resource module and the system management module when the task execution condition is triggered, and push the summarized task information to the task coordination module.

[0014] Moreover, the visible resource module is used to query the visible resource library according to the node partition number when receiving the execution trigger message sent by the task aggregation module, and push the visible resource information and resource occupancy status to the task coordination module; when the task coordination module is executed, the updated available information is updated to the visible resource library.

[0015] Moreover, the task coordination module pushes the information aggregation to the task execution cluster environment, sets the relevant scheduling algorithm according to the node status information from the system management module, schedules the task to the relevant node for execution according to the scheduling algorithm, and records the task execution status and node information; accepts the task execution results, pushes the updated visible resource information to the visible resource module according to the results, organizes the results according to the final output format requirements, and outputs the final results.

[0016] The solution of the present invention is simple and convenient to implement, has strong practicality, solves the problems of low practicality and inconvenience in actual application existing in related technologies, can improve user experience, and has important market value. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] Figure 1 It is a flow chart of a distributed mission planning system for a partitioned satellite constellation according to an embodiment of the present invention;

[0018] Figure 2 A logical diagram of a task planning application system according to an embodiment of the present invention;

[0019] Figure 3 This is a business logic flow chart of the task collection module according to an embodiment of the present invention. DETAILED DESCRIPTION

[0020] The technical solution of the present invention is described in detail below with reference to the accompanying drawings and embodiments.

[0021] In the embodiments of the present invention, in order to make the purpose, technical solutions and advantages of the present application more clear, the present application is further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and are not used to limit the present application.

[0022] On the one hand, the present invention provides a mission planning system for a satellite constellation, wherein the satellites are divided into four zones according to geographical layout, and all satellite nodes in the zones are deployed with a mission planning application system. Kubernetes is used to build a distributed computing software platform to complete distributed collaborative computing of cluster tasks, achieve dynamic scalability of system cluster scale and task scheduling, and ensure data consistency and high availability of services.

[0023] like Figure 1 As shown, the embodiment provides a multi-satellite emergency observation mission planning method: first, the transmission layer constellation used for mission planning is divided into four partitions according to the 0° and 180° longitudes and the equator, each partition has one and only one core node, and the others are ordinary nodes, and all satellite nodes in the partition are deployed with a mission planning application system, such as Figure 2 All nodes can receive access request information from users and converge to the core nodes in the partition. The core nodes evaluate the controlled beam resources and user requests according to the trigger mechanism, split the tasks as needed, form several independent subtasks and publish them to the distributed computing cluster for multi-satellite collaborative computing and collect the results, and finally output the beam scheduling results.

[0024] The present invention further proposes:

[0025] For mission planning, each partition has only one core node, and the others are ordinary nodes. All nodes can receive access request information from users and converge to the core node in the partition. Considering the dynamic characteristics of low-orbit satellites and the fixed characteristics of partitions, the composition of satellite nodes in each partition is dynamically changed, that is, the roles of core nodes and ordinary nodes in each partition need to be switched.

[0026] The Raft consensus algorithm is used to elect core nodes. The core nodes evaluate the controlled beam resources and user requests according to the trigger mechanism, split the tasks as needed, form several independent subtasks, publish them to the distributed computing cluster for multi-satellite collaborative computing and collect the results, and finally output the beam scheduling results.

[0027] The task planning application system is designed into five modules: system management module, task collection module, task aggregation module, visible resource module, and task coordination module. Ordinary nodes only run the system management module and task collection module, while core nodes run all modules.

[0028] The system management module needs to receive the partition information sent by the application auxiliary support node.

[0029] The task collection module maintains a task queue, and when the node receives a task library update message sent by the application auxiliary support software, it actively queries the task library, updates the task queue, and sends the task information to the task aggregation module of the core node in the partition.

[0030] The task aggregation module, when the task execution condition is triggered, needs to send a notification to the visible resource module and the system management module, and push the summarized task information to the task coordination module. The node also needs to maintain a new task list, which is responsible for storing tasks from ordinary nodes within the node. The node needs to contain a timer. The node needs to determine the task execution trigger condition based on the received task and the timer. There are two main triggering methods:

[0031] (1) Dynamic triggering: When the task aggregation module receives a task with a preset priority that needs to be executed first, it selects the nearest dynamic departure time based on the current time. When the dynamic trigger time is reached, it needs to send a notification to the visible resource module and the system management module, send the organized task set to the task coordination module, and reset the timer at the same time.

[0032] (2) Periodic triggering: When the timer expires, the organized task content is sent to the task coordination module, and a notification needs to be sent to the visible resource module and the system management module, and the timer is reset at the same time.

[0033] When the visible resource module receives the execution trigger message sent by the task aggregation module, it queries the visible resource library according to the node partition number and pushes the visible resource information and resource occupancy status to the task coordination module. When the task coordination module is executed, the updated available information is updated to the visible resource library.

[0034] The task coordination module aggregates and pushes this information to the task execution cluster environment. The cluster management software designs the relevant scheduling algorithm based on the node status information from the system management module:

[0035] In this module, in order to make the node used resources and node remaining resources calculated by the scheduler equal to the actual node used resources and node remaining resources in real time, the Kubernetes scheduling scheme is divided into three mechanisms according to its effect time:

[0036] (1) Pre-processing scheduling mechanism: A node readiness state controller module is designed in the Kubernetes cluster to detect whether the daemon Pod is already in a working state, that is, the Running state. Only when the daemon Pod on the node is in the Running state can the user business Pod be scheduled to this node. In addition, in order to ensure that the Pod obtains the minimum amount of computing resources required for normal operation, the Requests / Limits scheduling rule is used to design resource guarantee and resource overselling scheduling schemes to limit the maximum amount of computing resources used.

[0037] (2) Scheduling mechanism during decision-making: This mechanism mainly plays a role in the scheduler. The existing scheduling algorithms of Kubernetes are expanded to meet the scheduling requirements. In order to meet the application of affinity scheduling rules in the preprocessing scheduling mechanism and the scheduling requirements of special nodes, two pre-selection algorithms and two optimization algorithms are designed. The two pre-selection algorithms are the Pod affinity matching algorithm and the Pod tolerance matching algorithm, and the optimization algorithms are the Pod affinity scoring algorithm and the Pod taint tolerance scoring algorithm.

[0038] (3) Adaptive adjustment mechanism in operation: When the computing resources of a node are in short supply, some Pods are expelled from the node to other nodes (i.e., passive scheduling), and the computing resources of the node are recovered to reduce the load of the node and ensure the stability of the Kubernetes cluster. This mechanism is mainly implemented by designing reasonable hard thresholds and soft thresholds for each eviction semaphore according to the cluster status. A fault tolerance period is set in the soft threshold. When the value of resource shortage exceeds the soft threshold and the duration exceeds the fault tolerance period, the Pod on the node is expelled. The hard threshold is set higher. When this standard is reached, the Pod is forced to be expelled to ensure the stability of the node and avoid downtime or impact on user business.

[0039] Finally, according to the scheduling algorithm, the task is scheduled to the relevant node for execution, and the task execution status and node information are recorded. The task execution results are accepted, and the updated visible resource information is pushed to the visible resource module according to the results. The results are organized according to the final output format requirements and the final results are output.

[0040] For a specific embodiment, the specific implementation steps are:

[0041] Step 1:

[0042] Select core nodes: All nodes in the partition run the system management module and task collection module. Figure 3 ,The system management module receives the partition information uploaded by the application auxiliary support node, determines the partition to which each node belongs and the core node number and IP within the partition.

[0043] If there is a core node in the network, the satellite will forward the user request to the core node for processing through redirection, otherwise the request will be discarded. After the core node processes the request, the processing result will be fed back to the end user through the satellite network. If there is no core node, the Raft algorithm needs to be used to elect a core node.

[0044] During the election process, multiple candidates may initiate elections at the same time, which may result in votes being divided. Due to the high dynamics and long latency of satellite networks, the time it takes for the election algorithm to re-elect a new leader after the leader crashes is significantly increased. In order to address the problem that the election algorithm may take a long time to recover after the leader crashes, the Raft algorithm suitable for satellite networks is used.

[0045] The election process of the Raft algorithm is triggered by the heartbeat mechanism. After starting the distributed system, the status of all nodes is initialized to the follower state, and the term value is initialized to 0. After receiving the heartbeat message from the leader, the node will remain in the follower state. If no heartbeat message is received for a period of time, it means that the leader has not been detected within the timeout period of the node. The node changes from the follower state to the candidate state, increases the term value by 1, and starts to run for the leader. The election process is as follows:

[0046] (1) The node status changes from follower to candidate, and the term value increases by 1;

[0047] (2) The candidate votes for himself and sends RequestVote to other followers;

[0048] (3) Followers who receive the RequestVote message will vote for at most one candidate in the same term on a first-come, first-served basis, and will only vote for candidates whose log index value is at least as new as their own;

[0049] (4) The candidate will remain in the state of (2) until one of the following three situations occurs:

[0050] ① The node wins the election, that is, receives votes from the majority of nodes. Then it becomes the leader;

[0051] ② Another node becomes the leader, that is, receives the heartbeat message. Then the candidate changes its state to follower;

[0052] ③ After the election timeout timer times out and no leader is elected, a new round of voting will begin.

[0053] If a candidate receives votes from more than half of the nodes, it will win the election. The leader manages log replication and data synchronization. Each follower votes for at most one candidate on a first-come, first-served basis, which ensures that at most one candidate wins the election in each term. Once a candidate wins the election, it becomes the leader. It sends heartbeat messages to other followers to establish connections and avoid new elections.

[0054] While waiting for a vote, the candidate may receive a heartbeat message from the leader. If the leader's term is at least as long as the candidate's current term, the candidate considers the leader legitimate and returns to the follower state; otherwise, the candidate rejects the leader's message and remains in the follower state.

[0055] Step 2:

[0056] After knowing the number and IP address of the core node, the task collection module starts to accept user requests and forwards them to the task aggregation module of the core node in the partition. When the node receives the task library update message sent by the application auxiliary support software, it actively queries the task library and updates the task queue. And send the task information to the task aggregation module of the core node in the partition.

[0057] Step 3:

[0058] The task aggregation module pre-processes all tasks to determine whether there is a task that needs to be dynamically triggered. If there is, it triggers a schedule. If not, it waits for the next periodic schedule. During dynamic scheduling, the timer for periodic trigger scheduling is updated, and the minimum time interval for dynamic triggering is 1 minute. After each scheduling trigger is generated, the task that needs to be scheduled is taken out, and the visible resource status is obtained through the visible resource module. There are two main triggering methods:

[0059] (1) Dynamic triggering: When the task aggregation module receives a task with a preset priority that needs to be executed first, it selects the nearest dynamic departure time based on the current time. When the dynamic trigger time is reached, it needs to send a notification to the visible resource module and the system management module, send the organized task set to the task coordination module, and reset the timer at the same time.

[0060] (2) Periodic triggering: When the timer expires, the organized task content is sent to the task coordination module, and a notification needs to be sent to the visible resource module and the system management module, and the timer is reset at the same time.

[0061] When receiving the execution trigger message sent by the task aggregation module, the visible resource module queries the visible resource library according to the node partition number, and pushes the visible resource information and resource occupancy status to the task coordination module. When the task coordination module is executed, the updated available information is updated to the visible resource library.

[0062] Step 4:

[0063] The task coordination module evaluates and splits the task planning to be scheduled, publishes computing tasks to the distributed cluster through the corresponding channel, and returns the computing results. Kubernetes is mainly used. Kubernetes (K8S for short) is the operating system of the cloud native era and the most popular container orchestration management platform. K8S can easily perform cluster application deployment, expansion, reduction, self-healing mechanism, service discovery, load balancing, logging, monitoring and other functions, greatly reducing the workload of daily operation and maintenance.

[0064] In terms of scheduling, the default scheduling method of Kubernetes is static scheduling. When scheduling Pods, the scheduler uses the node's allocatable CPU, allocatable memory, the resource request amount of the Pod to be scheduled (CPU Request and Memory Request), and the resource request amount of the Pod running on the node (CPU Request and Memory Request) as the scheduling basis. In fact, the resources actually used by the Pod may be less than, equal to, or greater than the value of its resource request amount Request, so the node's used resources and node's remaining resources calculated by the scheduler are not necessarily equal to the actual node's used resources and node's remaining resources. In order to ensure the coordination and availability of the scheduling scheme design, the scheduling scheme designed in this project is divided into the following three stages according to its action time:

[0065] ① Pre-processing scheduling mechanism: This mechanism mainly takes effect before the Pod is created. According to the specific attributes of the nodes in the Kubernetes cluster (CPU performance, memory resources, running Pod information, etc.), the corresponding scheduling rules are designed in the Pod creation file.

[0066] ② Scheduling mechanism during decision-making: This mechanism mainly plays a role in the scheduler.

[0067] The existing scheduling algorithm is expanded to meet the scheduling requirements.

[0068] ③ Adaptive adjustment mechanism in operation: This mechanism mainly works after the Pod is created. After the Pod is created, some force majeure factors (such as node resource shortage and node downtime) may cause the Pod to be rescheduled.

[0069] (1) Pre-processing before scheduling

[0070] In the preprocessing scheduling mechanism, in order to solve the problems of daemon Pod status detection, Pod usage management of node resources, and special Pod scheduling requirements, this solution designs the following parts in the scheduling mechanism to improve the default scheduling solution.

[0071] ① Add a node readiness state controller based on the original Kubernetes module. Before the user business Pod is deployed on the Kubernetes cluster node, the daemon Pod needs to be deployed on each node. Although Kubernetes provides DaemonSets objects to solve this problem, DaemonSets cannot detect whether the daemon Pod has been successfully started. To address this problem, this solution designs a node readiness state controller module in the Kubernetes cluster to detect whether the daemon Pod is already in a working state, that is, the Running state. Only when the daemon Pod on the node is in the Running state can the user business Pod be scheduled to this node.

[0072] ② Use the Requests / Limits scheduling rules to design resource guarantee and resource overselling scheduling solutions. Each user business Pod has different requirements for node resources. Some Pods have greater requirements for memory and CPU usage. If they are assigned to a node with insufficient computing resources during scheduling, the performance of the service will be affected to a certain extent. Moreover, there are currently no restrictions on the use of node computing resources by user business Pods in Kubernetes. When the Kubernetes cluster is relatively small, it does not affect the stability of the entire cluster. As the business develops, the unlimited use of computing resources by Pods will also affect the stability of the cluster. Therefore, this solution limits the resource request amount of a specific Pod and constrains the resource request of the Pod when it is created. Design Requests and Limits resource management scheduling solutions to manage the use of node computing resources by Pods, ensure that Pods can obtain the minimum amount of computing resources required for normal operation, and limit the maximum amount of computing resources used.

[0073] ③ Use the LimitRange scheduling rule to manage the computing resources of the node. It is cumbersome and complicated to design a resource management plan for each user business Pod. Therefore, this project has designed a LimitRange resource management scheduling plan in Kubernetes to limit the overall scope of computing resource management in each namespace, that is, all Pods in the namespace follow this computing resource management plan.

[0074] ④ Design different scheduling rules and strategies for different business Pods to meet the needs. The default scheduling scheme of Kubernetes can meet most of the user's needs, such as evenly distributing and scheduling Pods to various nodes in the cluster, and scheduling according to the port usage status of the Pod and the health status of the node. However, in some specific application scenarios, such as affinity and mutual exclusivity between Pods, and designated scheduling of special nodes. The default scheduling scheme of Kubernetes cannot meet the needs of users, because the scheduling scheme needs to be designed according to specific needs.

[0075] (2) Decision optimization during scheduling

[0076] In the decision-making scheduling mechanism, in order to meet the application of affinity scheduling rules in the pre-processing scheduling mechanism and the scheduling requirements of special nodes, two pre-selection algorithms and two optimization algorithms are designed.

[0077] The pre-selection algorithms added to the Kubernetes scheduler are the Pod affinity matching algorithm and the Pod tolerance matching algorithm.

[0078] (3) Adaptive adjustment during operation

[0079] The purpose of designing an adaptive adjustment mechanism is to evict some Pods from a node to other nodes (i.e., passive scheduling) when computing resources are scarce on a certain node, and to reclaim computing resources on the node to reduce the load on the node and ensure the stability of the Kubernetes cluster. Two factors are mainly considered in this scheduling mechanism: First, under what circumstances are the computing resources of a node considered scarce? It should be ensured that the node does not produce "jitters" that affect business performance. Second, in extreme cases, a node may have multiple Pods of the same business. If the node generates eviction scheduling, it will affect the performance of the business. Considering the above two aspects, the following parts are designed in this solution to solve such problems.

[0080] ① According to the cluster status, design reasonable hard thresholds and soft thresholds for each eviction signal. For Pod passive scheduling, two thresholds are designed, namely hard threshold and soft threshold. The soft threshold sets a fault tolerance period. When the resource shortage value exceeds the soft threshold and the duration exceeds the fault tolerance period, the Pod on the node is expelled. The hard threshold is set higher. When this standard is reached, the Pod is forced to be expelled to ensure the stability of the node and avoid downtime or affecting user services.

[0081] ② Design a reasonable minimum recovery amount of expelled resources according to the cluster status to prevent node "jittering". Design different minimum recovery amounts of expelled resources according to different node computing resources. The purpose of this design is to avoid node "jittering" as much as possible. Consider the following scenario: If a node has just expelled some Pods, the node's resource usage has recovered to below the threshold. The scheduler believes that the node can be scheduled again and schedules the expelled Pod to this node again. The resource usage of this node exceeds the threshold again and eviction occurs, causing the node to jitter.

[0082] ③ Add a passive scheduling protection controller module based on the original Kubernetes module to ensure the stable operation of the core business. When the node eviction behavior occurs, the number of Pods of the core business should be guaranteed and the service quality of the core business should not be affected. Therefore, this solution sets up a passive scheduling protection controller module in the Kubernetes cluster to protect the number of core business Pods to be consistent with that before eviction. The design idea of ​​this controller is as follows: If a protected Pod is evicted, after a Pod is evicted, it must wait until the Pod is started on other nodes before the Pod of this type is evicted again. In layman's terms, if a Pod of this type is reduced on this node, a Pod of this type must be added on other nodes to ensure that the number of Pods of this type in the cluster is consistent and does not affect the core business.

[0083] When the core node sends the distributed cluster calculation, it initializes a timer and waits for the return of the distributed calculation results. The results that exceed the time threshold are discarded. The result with the highest benefit evaluation is selected from all the returned results as the final output result.

[0084] In specific implementation, the method proposed in the technical solution of the present invention can be implemented by technical personnel in this field using computer software technology to realize automatic operation process. System devices for implementing the method, such as computer-readable storage media storing the corresponding computer program of the technical solution of the present invention and computer equipment running the corresponding computer program, should also be within the scope of protection of the present invention.

[0085] The specific embodiments described herein are merely examples of the spirit of the present invention. Those skilled in the art may make various modifications or additions to the specific embodiments described or replace them in similar ways, but they will not deviate from the spirit of the present invention or exceed the scope defined by the appended claims.

Claims

1. A distributed satellite mission planning system, characterized in that: The invention is used for multi-satellite collaborative computing of distributed computing clusters, including dividing the global space into four zones, each zone performing independent task planning; all satellite nodes in the zone deploy a task planning application system to provide users with access request collection and task scheduling result feedback services, the task planning application system includes a system management module, a task collection module, a task aggregation module, a visible resource module and a task coordination module; the Raft consensus algorithm is used to elect core nodes, so that the core nodes in each zone are dynamically changed, and the role switching between core nodes and ordinary nodes is realized.

2. The distributed satellite mission planning system according to claim 1, characterized in that: Mission Planning The transport layer constellation is divided into four sectors according to the 0° and 180° longitudes and the equator.

3. The distributed satellite mission planning system as claimed in claim 2, characterized in that: For task planning, each partition has one and only one core node, and the others are ordinary nodes; all nodes can receive access request information from users and converge to the core node in the partition.

4. The distributed satellite mission planning system as claimed in claim 3, characterized in that: After the core node is elected using the Raft consensus algorithm, the core node evaluates the controlled beam resources and user requests according to the trigger mechanism, splits the tasks as needed, forms several independent subtasks, publishes them to the distributed computing cluster for multi-satellite collaborative computing and collects the results, and finally outputs the beam scheduling results.

5. The distributed satellite mission planning system as claimed in claim 4, characterized in that: Ordinary nodes only run the system management module and task collection module, while core nodes run all modules.

6. The distributed satellite mission planning system according to claim 5, characterized in that: The system management module receives the partition information sent by the application auxiliary support node.

7. The distributed satellite mission planning system according to claim 5, characterized in that: The task collection module maintains a task queue. When a node receives a task library update message sent by the application auxiliary support software, it actively queries the task library, updates the task queue, and sends the task information to the task aggregation module of the core node in the partition.

8. The distributed satellite mission planning system according to claim 5, characterized in that: The task aggregation module is used to send notifications to the visible resource module and the system management module when the task execution conditions are triggered, and push the summarized task information to the task coordination module.

9. The distributed satellite mission planning system according to claim 5, characterized in that: The visible resource module is used to query the visible resource library according to the node partition number when receiving the execution trigger message sent by the task aggregation module, and push the visible resource information and resource occupancy status to the task coordination module; when the task coordination module is executed, the updated available information is updated to the visible resource library.

10. The distributed satellite mission planning system according to claim 5, characterized in that: The task coordination module aggregates and pushes the information to the task execution cluster environment, sets the relevant scheduling algorithm according to the node status information from the system management module, schedules the task to the relevant node for execution according to the scheduling algorithm, and records the task execution status and node information; Accept the task execution results, push the updated visible resource information to the visible resource module according to the results, organize the results according to the final output format requirements, and output the final results.

Images