On-orbit calculation autonomous system for low-orbit satellite

Abstract

The invention provides an in-orbit calculation autonomous system for a low-orbit satellite. A satellite system is managed in a mode of dividing satellites in a constellation into a plurality of autonomous groups, a unified management mechanism and an in-autonomous-group management mechanism are constructed to construct a management system of the satellite autonomous groups, and a streaming computing task migration scheme sensitive to a geographic position is constructed to construct an over-the-ground communication optimization scheme of the satellite system. Through a grouping mode, the low-orbit satellites can be divided into a plurality of autonomous groups, and the pressure of management nodes is reduced; a dynamic grouping mechanism is introduced during grouping, so that the balance of calculation load borne by each group in the whole operation period is ensured; a decentralized satellite cluster self-organization and cooperation mode is provided, so that the high availability of the cluster and the robustness of task processing are improved; according to the designed streaming computing task migration scheme sensitive to the geographic position, the expenditure caused by frequent migration of the on-satellite computing task is reduced from two aspects of migration path selection and migration mechanism implementation.

Description

Technical Field

[0001] The present disclosure relates to the field of satellite communications, and more specifically, to an on-orbit computing autonomous system for low-orbit satellites. Background Art

[0002] With the continuous advancement of artificial satellite technology, low-orbit satellite communication networks have become an important part of the global communication system. The Starlink project launched by SpaceX in the United States is a typical example. This project aims to establish a global broadband Internet service network by deploying thousands of low-orbit satellites. At the same time, China is also promoting the development of low-orbit satellite technology. In 2020, the National Development and Reform Commission listed the "Satellite Internet" project as part of the construction of new infrastructure and elevated it to the level of a national strategic project.

[0003] In the past, satellite mission scheduling mainly relied on ground stations sending instructions to satellites within line of sight. This process requires satellites to strictly follow predetermined instructions and only update missions or transmit results when they reconnect with the ground station. However, the construction of ground stations is limited by cost and policy, and its control range is difficult to cover the numerous low-orbit satellites around the world, limiting the potential for global coverage of low-orbit satellites. At the same time, as the number of satellites increases, the data processing burden of the ground control center is increasing, showing the limitations of the existing control model.

[0004] These challenges have led to the need for offline autonomous management capabilities for low-orbit satellites to fully utilize the computing resources in the star network. Therefore, it is particularly important to develop an edge autonomous system that supports low-orbit satellites to autonomously perform computing tasks.

[0005] Some studies have used the KubeEdge edge node management framework to manage low-orbit satellites, using ground stations to build KubeEdge cloud components and manage satellite nodes as edge nodes.

[0006] KubeEdge requires a Kubernetes cluster built in a ground-based cloud center to manage the satellite. When the satellite leaves the control range of the ground station, it cannot be controlled and cannot perform new computing tasks during this period.

[0007] There are some studies on using K3s to manage satellite clusters and directly deploying K3s clusters in low-orbit satellite constellations.

[0008] Using K3s as a solution for satellite node management can achieve deployment with low resource consumption, and has good autonomy without relying on ground communication. However, K3s is based on a centralized design, and the K3s system on the ground can improve the availability of the cluster by increasing the number of replicas of the master node. In space conditions, once a node is damaged, it cannot be repaired, which limits the ability to maintain the number of replicas of the master node, posing a huge challenge to the long-term availability of the cluster.

[0009] In order to solve the challenge of time constraints for low-orbit satellite control, a study proposed the C3S (Constellation Cloud Computing System) architecture. This architecture combines the advantages of high-orbit satellites and low-orbit satellites. In C3S, low-orbit satellites serve as nodes for actual task processing, while geosynchronous orbit satellites play the role of master control. The master control satellite is responsible for receiving commands from the ground and directing its subordinate low-orbit satellites to allocate computing tasks. By synchronizing data between geosynchronous orbit satellites and based on the global coverage of high-orbit satellite communication range, C3S can overcome the problem of limited time windows for traditional ground stations to access low-orbit satellites.

[0010] The strategy of using geostationary orbit satellites (i.e. high-orbit satellites) to manage the low-orbit satellite cluster overcomes the effective range problem of low-orbit satellite control, but this solution involves sending commands from ground clients to geostationary orbit satellites, which then distribute computing task instructions to low-orbit satellites. Considering the high orbital position of geostationary orbit satellites, this control process will introduce relatively large communication delays.

[0011] Low-orbit satellite constellations usually have a large number of satellites, spread all over the world, and need to maintain high operational reliability in the extreme space environment. The goal of this invention is to design an optimized on-orbit computing autonomous system for the unique requirements and challenges of low-orbit satellite constellations operating in space.

[0012] First, when designing an on-orbit computing system for a low-orbit satellite constellation, a major challenge is the limited computing and storage resources of the satellite, which are relatively scarce due to the limitation of payload capacity. To effectively manage computing tasks across the entire constellation, the limited computing power of a single satellite is not enough. Therefore, adopting a divide-and-conquer strategy to divide the satellites in the constellation into multiple autonomous groups is an effective solution. When grouping, considering the wide distribution of satellites, those satellites located over densely populated areas may bear more computing tasks, while satellites over oceans or deserts face relatively lower computing requirements. In order to solve this problem, the present invention proposes a dynamic satellite grouping method based on spatiotemporal load prediction, which aims to achieve a balanced distribution of loads between satellite groups.

[0013] Secondly, when the grouping of satellites in the constellation is completed, the next thing to focus on is how to effectively organize and manage satellites in each autonomous group. Considering that low-orbit satellites have a high failure rate due to factors such as atmospheric resistance, this poses a challenge to maintaining the stability of satellite clusters. In the field of ground edge computing, for example, using technologies such as K3s, centralized management and master-slave node switching mechanisms are usually used to improve the availability of the system. However, in space, satellite computing nodes cannot be maintained or replaced like ground equipment, and the number of copies of the backup nodes of the master node cannot be guaranteed for a long time, which makes the high-availability method that relies on centralized backup nodes face greater challenges. Therefore, the present invention proposes a decentralized method to enhance the stability of the satellite cluster through self-organization and collaboration mechanisms to ensure that the system can continue to operate even when key nodes fail. This method also supports the aforementioned dynamic satellite grouping strategy, enhancing the adaptability and long-term stability of the low-orbit satellite cluster.

[0014] Finally, in scenarios where low-orbit satellites provide computing services, devices such as drones and ground vehicles need to continuously send data to satellites for real-time online stream processing. However, due to the rapid movement of low-orbit satellites, their coverage time for ground equipment is usually very limited, only about tens of minutes. Therefore, when performing these tasks, in order to maintain the responsive computing quality of streaming data processing, computing tasks must be effectively migrated. Taking into account computing tasks that need to be frequently migrated on satellites, the present invention aims to reduce the number of task migrations and shorten the service interruption time caused by migration by optimizing the migration route selection and the migration strategy of computing tasks. Summary of the invention

[0015] The purpose of the embodiments of the present disclosure is to provide an on-orbit computing autonomous system for low-orbit satellites, and its purpose is to design an optimized on-orbit computing autonomous system for the unique needs and challenges of low-orbit satellite constellations operating in space.

[0016] In a general aspect, an on-orbit computing autonomous system for low-orbit satellites is provided, which manages the satellite system by dividing the satellites in the constellation into multiple autonomous groups, constructs a unified management mechanism and an intra-autonomous group management mechanism to construct a management system for the satellite autonomous group, and constructs a geographically sensitive streaming computing task migration scheme to construct an optimization scheme for satellite system communication with the ground;

[0017] The unified management mechanism implements node management and task allocation within the autonomous group for satellite nodes in the low-pass satellite constellation by constructing a load-aware satellite autonomous group dynamic partitioning strategy, and uniformly manages the satellite nodes;

[0018] The intra-group management mechanism, based on determining the grouping of satellite constellations, organizes and manages by building a decentralized satellite cluster self-organization and collaboration mechanism within the autonomous group, so as to take into account the needs of satellite automatic grouping strategy and the dynamic changes of node online and offline states to deal with key node failures;

[0019] The geographically-sensitive streaming computing task migration solution migrates computing tasks by optimizing migration path selection and streaming computing task migration strategies, thereby reducing the frequency and cost of online streaming computing task migration and shortening service interruption time caused by migration.

[0020] The load-aware satellite autonomous group dynamic division strategy is constructed by considering the satellite load conditions at different time and space positions to divide the groups. First, the satellite load index is modeled based on the existing geographic device density index data and the traffic ratio changes throughout the day to define the future real-time load of the satellite. Then, a dynamic satellite grouping mechanism using spatiotemporal load prediction is designed to predict the load conditions of each satellite in the next certain period of time, and pair high-load satellites with low-load satellites to achieve dynamic grouping adjustment.

[0021] The implementation method of the dynamic satellite grouping mechanism using spatiotemporal load prediction is as follows: for a low-orbit satellite constellation, the satellite sub-satellite point trajectory coordinates are obtained through the SGP algorithm, and the satellite sub-satellite point trajectory coordinates, the ground area equipment static density index, and the real-time traffic ratio distribution are input into a load calculation unit. The load calculation unit predicts the future real-time load of the satellite through the input data to calculate the average load index in the future time period, and generates satellite groups through a grouping algorithm.

[0022] The specific method of modeling is: the load index L of satellite i at time T i (T): L i (T) = D (Lat i (T),Lon i (T))×F(G(Lat i (T))), where D(Lat i ,Lon i ) represents the coordinates (Lat i ,Lon i ) corresponding to the static density index of the device, Lat i (T) and Lon i (T) respectively represent the longitude and latitude of the subsatellite point coordinates of satellite i at time T, F(t) is the flow ratio corresponding to the time zone t corresponding to the subsatellite point trajectory of the satellite within a day, G(Lat i (T)) represents the time zone time t calculated based on longitude and UTC time T;

[0023] The method for obtaining the average load index in the future time period is as follows: a low-orbit satellite constellation consisting of N satellite nodes is set, and the set of satellite nodes of this constellation is represented as S, that is, S = {s1, s2, s3, ..., s N-1 ,s N}, each element in the set represents a separate satellite node; then define the satellite node s i The average load index from the start time t0 to the future time period t0+ΔT

[0024]

[0025] m represents the number of samplings, and t0 is the time point when sampling starts;

[0026] The standard deviation of the average load index between groups is used as the evaluation indicator. i , the group contains n satellites, represented as a set {s i1 ,s i2 ,…,s in}, at time T, the average load index Load of the group is used avg (cluster i ) represents the average value of all satellite load indices in the group:

[0027]

[0028] The process of generating satellite groups by using the grouping algorithm is as follows: using a genetic algorithm to minimize the standard deviation of the average load index of each group.

[0029] The specific content of the decentralized satellite cluster self-organization and collaboration mechanism is as follows: construct a satellite cluster collaboration model based on peer nodes, set up a leadership node, called the Leader node, to serve as the management center of the cluster, and other nodes except the Leader node are called Follower nodes, which serve as the submission, distribution and processing mechanism of satellite grouping tasks, and build an information consistency guarantee mechanism to keep the task consensus information and satellite grouping information updated and accurate. On this basis, a dynamic self-organization mechanism of satellite nodes is constructed as a dynamic selection mechanism of the leader node, thereby forming a self-organization and collaboration mechanism of the satellite cluster.

[0030] The logic of the satellite cluster collaboration model based on peer nodes is that the ground-end devices submit tasks to the access point satellites closest to them, and transmit metadata descriptions of the computing tasks and file data required for task execution during the task submission process;

[0031] After receiving the file data required for calculation, the access satellite will adopt a multi-copy strategy, and the file data is stored on several fixed nodes in the group to which it belongs;

[0032] Next, the access satellite integrates the file path information corresponding to the task into the metadata description of the task, and forwards the updated metadata information to the leader node of the group to which it belongs; the distributed task consensus set mechanism is used as the information consistency guarantee mechanism, and the Raft algorithm is applied to maintain the consistency of information and record the task metadata within the cluster. When the leader node receives the new task metadata, it refers to the distributed task consensus set and selects the node suitable for executing the task based on the current load of the nodes in the group. After the selection is completed, the leader node updates the details of the execution node to the corresponding field in the task metadata, and further adds the updated task information to the distributed task consensus set;

[0033] Finally, the nodes in the autonomous group regularly check the task information in the distributed task consensus set. If they find that the node ID specified by the task is consistent with their own ID, they will add the task to their own queue for processing. After the task is processed, the relevant task will be removed from the task set.

[0034] The dynamic self-organizing mechanism of the satellite nodes is realized through the dynamic construction process of the satellite autonomous group and the offline state detection and processing mechanism of the satellite nodes;

[0035] The dynamic construction process of the satellite autonomous group is as follows: when the current leading node encounters a problem, a certain node A will trigger the regrouping mechanism at a fixed time, update itself to the "unschedulable" state in the cluster state consensus table to enter the regrouping state, and apply to other group members to be the leader; if the current cluster has no leader, then node A will automatically become the new leading node and process requests from other nodes to join the cluster; if the cluster already has a leading node, there are two situations: if the ID of the current leading node is larger than that of node A, then the current leading node only needs to include node A in the Raft configuration. Conversely, if the ID of the current leading node is smaller than that of node A, then after adding node A to the Raft configuration, the current leading node needs to start the leadership transfer process and hand over the leadership node position to node A;

[0036] The satellite node offline status detection and processing mechanism includes three parts: offline node detection mechanism, offline node task migration, analysis of the impact of node offline on cluster availability and solutions.

[0037] The specific process of the offline node detection mechanism is as follows: the leader node periodically sends heartbeat signals to other nodes. When the follower node receives the heartbeat signal of the leader node, it feeds back its survival status to the leader. If a follower node does not respond to the leader's heartbeat within a specified number of times, the leader will regard it as an offline node and trigger the task migration mechanism of the corresponding offline node.

[0038] The task migration mechanism of the offline node is as follows: when the leader node identifies that a follower node in the cluster is offline, it obtains the details of the pending tasks on the offline node, and then, by applying a load balancing method, the leader node reallocates these tasks to other online nodes in the cluster;

[0039] The analysis of the impact of node offline on cluster availability and the solution are as follows: when a node goes offline, the Leader node triggers the Raft member configuration adjustment program, removes the offline node from the Raft cluster configuration, and updates the cluster member information.

[0040] The proposed geographically sensitive streaming computing task migration scheme first constructs a migration path selection strategy based on latency constraints to reduce the number of migrations. It is recommended that ground terminals select the nearest satellite as the access point to minimize the latency from the ground to the access satellite. Finally, a pre-migration mechanism with a stateful computational graph is designed to achieve task migration through four steps.

[0041] Specifically, step 1: the access satellite sends a snapshot creation instruction to the satellite in the service phase according to the event control strategy based on the data flow. After receiving this request, the satellite node in the service phase starts to make a snapshot of the stateful computation graph;

[0042] Step 2: After the snapshot is completed, the service node transmits the snapshot data to the preheating node, and the preheating node uses this data and the execution information of the streaming task to build a new calculation graph;

[0043] Step 3: From the moment the second node is entered until the migration operation is triggered, the access satellite sends the data stream to both the old computation graph in the service phase and the new computation graph in the warm-up phase;

[0044] Step 4: When the input reaches the migration destination node, the migration operation is triggered, the access satellite is replaced, the preheated node becomes the new service node, and the original access satellite continues to use the cached data to synchronize to the new calculation graph. At the same time, the new access satellite only sends data to the new service node. The new data is cached until the new calculation graph finishes processing the old data before starting to process the new data.

[0045] In another aspect, an on-orbit computing autonomous system for low-orbit satellites is provided, and an on-orbit computing autonomous system architecture for low-orbit satellites is used to carry an on-orbit computing autonomous system for low-orbit satellites, and its specific architecture includes:

[0046] Service layer: acts as an intermediary between the client and satellite nodes, providing interfaces for obtaining node information, submitting geographically independent tasks and streaming tasks;

[0047] Consensus layer: builds a dynamic and scalable Raft cluster, monitors changes in node status, updates cluster status information, and manages the dynamic joining and exit of nodes;

[0048] Geographically independent task processing layer: schedules and processes geographically independent tasks within the cluster, allocates tasks by adjusting the task consensus set of the consensus layer, and establishes a task queue on each node based on the task metadata provided by the consensus layer. Tasks are processed in a containerized manner and the calculation results are returned after completion.

[0049] Stream computing task processing layer: parses the streaming computing task description submitted by the client, and arranges operators based on the data flow relationship between operators to create and execute streaming computing tasks, and implements the geographical location-sensitive streaming computing task migration solution strategy proposed in the present invention;

[0050] Infrastructure layer: provides the underlying operating environment for satellite computing nodes, covering container runtime, storage system, ephemeris calculation and operator library, supports consensus layer, geographical location-independent task processing layer and streaming computing task processing layer, provides storage capacity, container execution function, operator execution environment and ephemeris information.

[0051] The construction of a dynamically scalable Raft cluster is achieved through a Raft consensus and information storage module with a dedicated architecture; the monitoring of node status changes is achieved through a node status monitoring and cluster member change module with a dedicated architecture; the streaming computing task processing layer is achieved through a streaming computing orchestration and startup module with a dedicated architecture. The technical effects to be achieved by the present invention are:

[0052] (1) By grouping, low-orbit satellites can be divided into multiple autonomous groups, which reduces the number of nodes that the management node in the group needs to manage and reduces the pressure on the management node.

[0053] (2) Dynamic grouping mechanism is introduced during grouping to ensure the balance of computing loads borne by each group during the entire operation cycle.

[0054] (3) The proposed decentralized satellite cluster self-organization and collaboration method selects the leader node through election and uses the Raft algorithm to maintain the cluster status information and the metadata information of the computing task. When the leader node fails, the leader node can be re-elected, which improves the high availability of the cluster. At the same time, when the non-leader node in the cluster expires, it can be rescheduled to other nodes based on the update of the task metadata consensus table, which improves the robustness of task processing.

[0055] (4) The designed geographical location-sensitive streaming computing task migration scheme reduces the overhead caused by the frequent migration of on-board computing tasks from two aspects: migration path selection and migration mechanism implementation. BRIEF DESCRIPTION OF THE DRAWINGS

[0056] The above and other objects and features of the present disclosure will become more apparent from the following description in conjunction with the accompanying drawings.

[0057] Figure 1 is a schematic diagram showing steps of a satellite grouping method based on spatiotemporal load prediction according to an embodiment of the present disclosure;

[0058] Figure 2 is a logical schematic diagram showing a satellite node peer architecture according to an embodiment of the present disclosure;

[0059] Figure 3 is a flowchart showing a process of job submission and distribution in satellite grouping according to an embodiment of the present disclosure;

[0060] Figure 4 is a diagram showing a cluster architecture based on Raft according to an embodiment of the present disclosure;

[0061] Figure 5 is a flowchart showing a satellite node self-organization according to an embodiment of the present disclosure;

[0062] Figure 6 is a schematic diagram showing a mechanism for offline node task migration according to an embodiment of the present disclosure;

[0063] Figure 7 is a flowchart illustrating a process of a failed node according to an embodiment of the present disclosure;

[0064] Figure 8 is a schematic diagram showing a candidate satellite set based on delay constraints according to an embodiment of the present disclosure;

[0065] Fig. 9 is a schematic diagram showing an event control method based on data flow according to an embodiment of the present disclosure;

[0066] Fig.10is a diagram showing the phase division of satellites on a migration path according to an embodiment of the present disclosure;

[0067] Fig.11 is a schematic diagram showing a pre-migration mechanism of a stateful computation graph according to an embodiment of the present disclosure;

[0068] Fig.12 is a diagram showing the overall architecture of a SatWeave system according to an embodiment of the present disclosure;

[0069] Fig.13 is a diagram showing the Raft consensus and storage module architecture according to an embodiment of the present disclosure;

[0070] Fig.14 is a schematic diagram showing message communication processing between Raft nodes according to an embodiment of the present disclosure;

[0071] Fig.15 is a diagram showing the architecture of a Raft node status monitoring and cluster member maintenance module according to an embodiment of the present disclosure;

[0072] Fig.16 is a timing diagram showing a node regrouping process according to an embodiment of the present disclosure;

[0073] Fig.17 is a timing diagram showing streaming task scheduling and startup according to an embodiment of the present disclosure;

[0074] Fig.18 is a diagram showing a data flow and event control module architecture according to an embodiment of the present disclosure;

[0075] Fig.19 is a flowchart showing a stateful computation graph snapshot production process according to an embodiment of the present disclosure;

[0076] Fig. 20 It is a schematic diagram showing the interaction of components during the migration process according to an embodiment of the present disclosure. DETAILED DESCRIPTION

[0077] The following specific embodiments are provided to help the reader obtain a comprehensive understanding of the methods, devices and / or systems described herein. However, after understanding the disclosure of the present application, various changes, modifications and equivalents of the methods, devices and / or systems described herein will be clear. For example, the order of operations described herein is only an example and is not limited to those orders set forth herein, but can be changed as will be clear after understanding the disclosure of the present application, except for operations that must occur in a specific order. In addition, for greater clarity and simplicity, the description of features known in the art may be omitted.

[0078] The features described herein can be implemented in different forms and should not be construed as being limited to the examples described herein. Rather, the examples described herein have been provided to illustrate only some of the many possible ways to implement the methods, devices, and / or systems described herein, which will be clear after understanding the disclosure of the present application.

[0079] As used herein, the term "and / or" includes any one of the associated listed items and any combination of any two or more.

[0080] Although terms such as "first", "second", and "third" may be used herein to describe various members, components, regions, layers, or portions, these members, components, regions, layers, or portions should not be limited by these terms. Instead, these terms are only used to distinguish one member, component, region, layer, or portion from another member, component, region, layer, or portion. Therefore, without departing from the teachings of the examples described herein, the first member, first component, first region, first layer, or first portion referred to in the examples may also be referred to as the second member, second component, second region, second layer, or second portion.

[0081] In the specification, when an element (such as a layer, a region or a substrate) is described as being “on”, “connected to” or “coupled to” another element, the element may be directly “on”, “connected to” or “coupled to” another element, or one or more other elements may be present therebetween. Conversely, when an element is described as being “directly on”, “directly connected to” or “directly coupled to” another element, there may be no other elements present therebetween.

[0082] The terms used herein are only used to describe various examples and are not intended to limit the disclosure. Unless the context clearly indicates otherwise, the singular form is also intended to include the plural form. The terms "comprise", "include" and "have" indicate the presence of the described features, quantities, operations, components, elements and / or combinations thereof, but do not exclude the presence or addition of one or more other features, quantities, operations, components, elements and / or combinations thereof.

[0083] Unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as those generally understood by a person of ordinary skill in the art to which the present disclosure belongs after understanding the present disclosure. Unless explicitly defined as such herein, terms (such as those defined in a general dictionary) should be interpreted as having a meaning consistent with their meaning in the context of the relevant art and the present disclosure, and should not be interpreted in an idealized or overly formal manner.

[0084] Furthermore, in the description of examples, when it is considered that a detailed description of a well-known related structure or function would cause vague interpretation of the present disclosure, such a detailed description will be omitted.

[0085] The present invention comprises the following four parts:

[0086] 1. Load-aware dynamic division strategy of satellite autonomous groups

[0087] In a low-pass satellite constellation, there are many satellite nodes, but the computing and storage resources they can carry are relatively limited due to payload capacity constraints. A single or a few satellites with limited resources find it difficult to cope with node management and computing task scheduling for the entire constellation. Therefore, a divide-and-conquer strategy is adopted to divide the satellites in the constellation into multiple autonomous groups, which can achieve node management and task allocation within the autonomous groups, and effectively solve the problem that many satellite nodes are difficult to manage in a unified manner. Taking into account the diversity of ground personnel activities, satellites over areas with dense human activities on the ground will undertake more computing tasks, while satellites over sparsely populated areas such as oceans and deserts face fewer computing needs. In order to achieve a balance in the load of nodes within a group, the present invention proposes a load-aware satellite autonomous group dynamic partitioning strategy, which aims to balance the load between groups.

[0088] 2. Decentralized satellite cluster self-organization and collaboration mechanism

[0089] After determining the grouping of the satellite constellation, the next step is to consider how to effectively organize and manage within the autonomous group. Due to the residual resistance of the atmosphere faced by low-orbit satellites, their on-orbit lifespan is relatively short. Coupled with factors such as power constraints, the computing nodes of the StarNet may be frequently and temporarily offline, which poses a challenge to maintaining the high availability of the cluster. The management of ground edge nodes usually adopts a centralized mode and a master-slave switching strategy (such as K3s) to ensure high availability by maintaining backup master nodes. However, in the space environment, it is very difficult to maintain a sufficient number of central backup nodes for a long time because satellites are difficult to repair or replace. Relying on a few central backup nodes, once a failure occurs, the entire system may be paralyzed. Therefore, the present invention proposes a decentralized design that emphasizes the self-organization and collaboration capabilities of satellite clusters to cope with key node failures without affecting the continued operation of the StarNet system. This design takes into account the needs of satellite automatic grouping strategies and the dynamic changes in the online and offline status of nodes, ensuring that the satellite group can maintain stable operation in the face of challenges.

[0090] 3.3. Geographically sensitive streaming computing task migration solution

[0091] In the application scenarios of satellite-borne edge computing, terminal devices such as drones and ground vehicles need to continuously transmit data to satellites for real-time online streaming computing processing. However, the rapid movement of low-orbit satellites means that their visibility to ground terminals is usually only 7 to 10 minutes, which poses a challenge to the continuity of data processing and service quality. To ensure this goal, computing tasks must be effectively migrated. Taking into account the sensitivity of these computing tasks to geographic location and the frequency of migration, the present invention will start from optimizing the migration path selection and the migration strategy of streaming computing tasks, with the aim of reducing the frequency and cost of online streaming computing task migration, while shortening the service interruption time caused by migration.

[0092] 4. Design and implementation of autonomous on-orbit computing system for low-orbit satellites

[0093] Based on the above technologies, the present invention provides the overall design of the low-orbit satellite on-orbit computing autonomous system and the specific implementation of the core modules.

[0094] The specific technical solution is:

[0095] 1. Load-aware dynamic division strategy of satellite autonomous groups

[0096] Low-orbit satellites are well-known for their ability to cover almost all areas of the Earth, but their widespread distribution also brings challenges: satellites over different regions, such as densely populated areas and remote sea areas or deserts, have significantly different mission loads. In order to improve the efficiency of satellite resource utilization, this study proposes a load-aware dynamic satellite grouping method. This method groups satellite loads at different time and spatial locations to optimize the utilization efficiency of the entire constellation.

[0097] 1. Satellite spatiotemporal load modeling based on geographic and traffic information

[0098] Due to the lack of real on-board load condition data, the present invention first models the satellite load index based on the existing geographic equipment density index data and the flow ratio changes throughout the day, and makes a definition as shown in Table 1.

[0099] Table 1. Spatial-temporal load prediction modeling parameters

[0100]

[0101] in:

[0102] L i (T) = D (Lat i (T),Lon i (T))×F(G(Lat i ,T))#

[0103] D(Lati (T),Lon i (T)) corresponds to the device density of the area where the subsatellite point of the current satellite i is located at time T. This item can reflect the overall computing demand of the area, while F(G(Lat i ,T)) reflects the proportion of the computing demand in the time zone where the sub-satellite point is located in the whole day, so it is logical to define the product of the two as the load index of satellite i at time T.

[0104] 2. Satellite dynamic grouping method based on spatiotemporal load prediction

[0105] After obtaining the real-time satellite load data, the present invention designs a dynamic satellite grouping mechanism using spatiotemporal load prediction. The core of this method is to predict the load of each satellite in the next certain period of time, and pair high-load satellites with low-load satellites to achieve dynamic grouping adjustment. This method aims to balance the load within each group and ensure the operating efficiency of the entire constellation. The specific process of this grouping strategy based on load prediction is as follows: Figure 1 shown.

[0106] For the convenience of description, the present invention makes the following definitions:

[0107] Suppose a low-orbit satellite constellation consisting of N satellite nodes, and denote the set of satellite nodes of this constellation as S, that is, S = {s1, s2, s3, …, s N-1 ,s N}. Here each s i Represents a single satellite node. Then, the present invention further defines a satellite node s i The average load index from the starting time t0 to the future time period t0+ΔT is expressed as This index measures the average load level during the period from t0 to t0+ΔT. In order to calculate this index, the present invention proposes a method of performing discrete sampling and calculating the average value during the ΔT period. Here, m represents the number of samplings, t0 is the time point when sampling starts, and the average load index is The calculation formula is as follows:

[0108]

[0109] In order to measure the load status of satellites in a cluster, the present invention uses the standard deviation of the average load index between clusters as an evaluation index. i , the group contains n satellites, represented as a set {s i1 ,s i2 ,…,s in}. At time T, the average load index of the group is Load avg (clusteri ) represents the average value of all satellite load indexes in the group. The specific formula is as follows:

[0110]

[0111] At this point, the grouping goal of low-orbit satellites can be described as: minimizing the standard deviation of the average load index of each group. For this problem, the present invention uses a genetic algorithm to process satellites. Under the genetic algorithm framework, each grouping scheme (individual) is represented as an array whose length is equal to the number of satellites in the constellation, and each element in the array represents the group to which the corresponding satellite belongs. We define the fitness function as the negative value of the standard deviation of the average load index between groups in order to minimize the standard deviation. In addition, in order to ensure that the number of satellites in the group is roughly equal, specific constraints are imposed when performing the crossover and mutation steps of the genetic algorithm. The pseudo code of the genetic algorithm used for grouping is shown below.

[0112]

[0113]

[0114] 2. Decentralized satellite cluster self-organization and collaboration

[0115] After dividing the satellite autonomous groups, the next task is to consider how to effectively organize and manage the satellite nodes in the group. Although it is possible to consider using edge node management technologies such as K3s to manage the satellite cluster, such technologies are often based on a centralized architecture. However, satellites cannot be repaired or replaced, and this feature makes it difficult for centralized management strategies that rely on central nodes to ensure long-term reliable operation. Therefore, this section introduces a decentralized satellite cluster self-organization and collaboration mechanism to achieve the continuous and stable operation of the StarNet cluster.

[0116] 1. Satellite cluster collaboration model based on peer nodes

[0117] To ensure the continuous operation and availability of the low-orbit satellite constellation, this paper proposes a decentralized management method that organizes the satellites in the constellation as equal participants. In this architecture, satellites cooperate with each other through interplanetary collaboration interfaces, such as Figure 2 In this architecture, each satellite has the following capabilities:

[0118] 1. The ability to collect and record task metadata.

[0119] 2. The ability to completely collect and record basic information of all nodes in the constellation.

[0120] 3. Ability to complete computing tasks.

[0121] 4. The ability to act as a cluster coordinator.

[0122] In order to improve the management efficiency and task allocation capability of the cluster, in a satellite autonomous system composed of peer nodes, the present invention establishes a leadership node, called a Leader node, to serve as the management center of the cluster. In this system, nodes other than the Leader node are called Follower nodes. It is worth noting that the Leader node in the autonomous system is not permanently fixed, but is determined by elections between nodes. This means that each node has the potential to become a Leader. If the current Leader node encounters a problem, other nodes in the system will quickly conduct a new round of elections to select a new Leader node. This flexible election mechanism significantly improves the stability and reliability of the entire autonomous system, ensuring that the management and coordination functions of the cluster can continue to operate even in extreme space environments.

[0123] Next, the submission, distribution, and processing procedures of offline computing tasks within the autonomous group of low-orbit satellites will be elaborated in detail.

[0124] The task distribution process diagram is as follows: Figure 3 shown.

[0125] The process from task submission to processing is described as follows:

[0126] (1) When the ground equipment submits a task to the access point satellite, it needs to transmit the metadata description of the computing task and the file data required to execute the task. The task metadata description format designed in the present invention is shown in Table 2.

[0127] Table 2 Computing task metadata description

[0128]

[0129] (2) After receiving the file data required for calculation, the access satellite will adopt a multi-copy strategy to store the file data on several fixed nodes in the group to which it belongs. This is done to prevent the risk of file data loss due to access node failure before the task is completed.

[0130] (3) Then, the access satellite integrates the file path information corresponding to the task into the metadata description of the task, and forwards the updated metadata information to the leader node of the group to which it belongs.

[0131] (4) The present invention proposes a mechanism called Distributed Task Consensus Set (DTCS) for recording task metadata within the cluster. The management mechanism of this consensus set will be described in detail in the consistency guarantee of information below. When the leader node receives new task metadata, it will refer to DTCS and select nodes suitable for executing the task based on the current load of the nodes in the group. After the selection is completed, the leader node will update the details of the execution node to the corresponding field in the task metadata, and further add this updated task information to DTCS.

[0132] (5) The node periodically checks the information in the distributed task consensus set and adds the pending tasks to its own pending queue. After the task is processed, the relevant task will be removed from the task set.

[0133] 2. Information consistency assurance

[0134] The above article introduces the task distribution mechanism of satellite grouping. To achieve this goal, each satellite autonomous group needs to jointly maintain a consensus set on task metadata. In addition, in order to support dynamic satellite grouping strategies and collaborative interactions between satellites, each node must understand the existence, scheduling status and communication details of other members in its group. Therefore, in the design of this system, keeping the task consensus information and satellite grouping information updated and accurate has become a core task. The details and functions of these two types of information are shown in Table 3.

[0135] Table 3. Consistency information in each satellite group cluster

[0136]

[0137] The present invention uses the Raft protocol to ensure the consistency of information of each node. Each satellite node executes a Raft protocol process and ensures that each node can maintain the integrity and consistency of cluster and task metadata information through the storage function of memory or embedded database. Figure 4 3. Dynamic self-organization mechanism of satellite nodes

[0138] Satellite computing nodes frequently go online and offline in a cluster due to dynamic grouping mechanisms and energy consumption. In view of the dynamic changes of satellite computing nodes frequently going online and offline in a cluster, an autonomous satellite cluster must adopt a management method that can automatically adapt to these changes. This section will explore how the system designed by the present invention copes with the challenge of satellite nodes frequently going online and offline, including the impact of node status changes on cluster configuration and task processing. Because the node online process is only a part of the satellite autonomous group construction process, the present invention will focus on two key aspects: the dynamic construction process of the satellite autonomous group and the detection and processing method of the satellite node offline status.

[0139] Satellite autonomous group dynamic construction process:

[0140] In this system, each node manages a "Term" field, whose value will increase when entering the regrouping phase to identify whether the node belongs to the same grouping cycle. When the regrouping mechanism is started, the node will update itself to the "unschedulable" state in Group Info. After completing all pending tasks, it will increase the Term value, enter the regrouping state, and stop responding to the heartbeat signal from the original group leader node. It is worth noting that this system uses the Raft algorithm to ensure information consistency, but it is unreasonable to directly apply the Raft algorithm to elect members of the new group during regrouping, because Raft elections require support from more than half of the nodes in the configuration, and the time for each node in the new group to complete the pending tasks is different, resulting in the time of entering the regrouping being out of sync, which may result in the failure to obtain the support of more than half of the nodes, thus making the cluster unable to operate normally. To this end, we have designed a strategy, that is, adding nodes in the regrouping state to the Raft configuration one by one. This method can effectively avoid the above problems and ensure the stability of the cluster.

[0141] In response to the needs of this specific scenario, the present invention makes adjustments based on the Raft algorithm and introduces the election mechanism in the Bully algorithm to select the Leader, giving priority to nodes with larger satellite IDs as the leaders of the cluster. The detailed flowchart of this process is shown in Figure 5 middle.

[0142] Take node A as an example. After entering the regrouping state, it will apply to other group members to become the leader according to the group list generated by the dynamic grouping algorithm described above. If there is no leader in the current cluster, node A will automatically become the new leader and handle requests from other nodes to join the cluster. If the cluster already has a leader, there are two situations: If the current leader's ID is larger than node A's, the current leader only needs to include node A in the Raft configuration. Conversely, if the current leader's ID is smaller than node A's, after adding node A to the Raft configuration, the current leader needs to start the leadership transfer process and hand over the leader position to node A.

[0143] Satellite node offline status detection and processing mechanism:

[0144] 1. Detection mechanism for offline nodes

[0145] As mentioned above, the Leader node is generated through the election process of the Raft protocol. In the Raft protocol, in order to maintain its leadership, the Leader node needs to periodically send heartbeat signals to other nodes. The present invention optimizes this heartbeat mechanism: when the Follower nodes receive the heartbeat signal of the Leader node, they also need to feedback their survival status to the Leader. If a Follower node does not respond to the Leader's heartbeat within the specified number of times, the Leader will regard it as an offline node and trigger the corresponding offline recovery process.

[0146] 2. Task migration of offline nodes

[0147] When the Leader node identifies that a Follower node in the cluster is down, its first operation is DTCS to obtain the details of the pending tasks on the offline node. Next, by applying round robin or other load balancing methods, the Leader will reallocate these tasks to other online nodes in the cluster and update DTCS accordingly. Considering that the geographically independent tasks we are discussing are not affected by geographical location, these tasks can be assigned to any online node for execution. After the DTCS is updated, the pending tasks originally assigned to the offline node will be transferred to other nodes. The schematic diagram of this process is shown below. Figure 6 shown.

[0148] The entire satellite node offline status detection and processing mechanism process is as follows Figure 7 Shown

[0149] 3.3. Geographically sensitive streaming computing task migration solution

[0150] Among the use cases of on-orbit low-orbit satellite computing, there is a type of streaming computing tasks that are sensitive to geographical location and require the satellite to be able to provide instant computing response.

[0151] The fast movement of low-orbit satellites means that the distance between ground terminals and satellites performing missions will gradually increase over time. This leads to an increase in the data transmission time from ground terminals to satellites. In order to maintain the low latency characteristics of online services, it is necessary to migrate computing tasks in a timely manner to match the continuous changes in satellite positions.

[0152] Considering the predictability of satellite orbits, the system can use ephemeris data to predict the future position and arrival time of satellites. The present invention optimizes the migration process of online streaming computing tasks by selecting computing task migration paths and designing migration mechanisms.

[0153] 1. Migration path selection strategy based on latency constraints

[0154] In the online streaming computing scenario of low-orbit satellites, the leader node in the satellite group is responsible for converting the logical definition of the streaming computing tasks submitted by ground users into a physical execution graph and performing task scheduling. According to the grouping scheme proposed in the present invention, the satellites in the same autonomous group may be located far away from each other. If the computing tasks are assigned to different satellites for execution, the end-to-end delay between operators may increase significantly. Therefore, the document recommends scheduling the entire streaming task to a single satellite node for execution, in order to reduce the communication delay between operators.

[0155] There are usually two strategies for selecting satellites for terminal access and satellites for mission execution: one is to select the satellite closest to the terminal (i.e., the "shortest distance strategy"), and the other is to select the satellite with the longest communication time with the ground equipment (called the "longest visible time strategy"). The 3600-second online streaming computing service simulation experiment in the Beijing area shows the difference between the two strategies in terms of latency and migration times. The specific data is shown in Table 4.

[0156] Table 4 Comparison of latency and migration times of different migration strategies

[0157]

[0158] The data in Table 4 show that although the shortest distance strategy significantly reduces latency, it will result in more service migrations. In contrast, the longest visible time strategy reduces the frequency of migrations and mitigates the impact of frequent migrations, but at the expense of increased latency. In actual application scenarios, the latency requirements of some tasks may not need to be as strict as the shortest distance strategy, and the latency provided by the longest visible time strategy cannot meet the requirements. In response to this situation, the present invention introduces a migration path selection strategy based on delay constraints, with the goal of minimizing the number of migrations while meeting the task latency requirements. To simplify the description, Table 5 lists the relevant symbol definitions used in this section.

[0159] Table 5 Symbolic definition of migration path selection strategy based on delay constraint

[0160]

[0161] The longitude and latitude of the ground terminal user u is known. u ,lon u ), we can calculate the communication delay Latency(u,Sat serve ). This delay is divided into two parts: one is from the ground terminal to the access satellite Sat in Latency(u,Sat in ), calculated according to formula (3.1); second, from the access satellite Sat in To the service satellite Sat serve Latency(Sat in ,Sat serve ), calculated by formula (3.2). The distance from the ground terminal u to the service satellite Sat serve The total communication delay Latency(u,Sat serve ) is obtained by formula (3.3). For each online streaming computing task, the ground terminal can set a delay limit latency. According to this delay limit, when processing the task, it is necessary to ensure that the delay constraint defined by formula (3.4) is met.

[0162]

[0163] Latency(Sat in ,Sat serve )=hop(Sat in ,Sat serve )×delay#(3.2)

[0164] Latency(Sat in ,Sat serve)=Latency(u,Sat in )+Latency(Sat in ,Sat serve )#(3.3)

[0165] Latency(u,Sat in )≤latency#(3.4)

[0166] In view of the two-stage characteristics of the above-mentioned delay calculation, the migration path selection strategy based on delay constraints proposed in the present invention recommends that the ground terminal select the nearest satellite as the access point to minimize the delay from the ground to the access satellite, that is, the calculation part according to formula (3.1). For the delay part involved in formula (3.2), the present invention determines the optional service satellite set for each access satellite based on the delay constraint latency in the task definition submitted by the ground terminal and the conditions defined by formula (3.4), such as Figure 8 exhibit.

[0167] exist Figure 7 In the scenario shown, Sat1 and Sat2 represent the access satellites closest to the ground terminal at time t0 and t0+τ, respectively. For Sat1 and Sat2, we can identify the candidate calculation satellite sets that meet the delay requirements, namely S1={S 11 ,S 12 ,S 13 ,…,S 1n} and S2={S 21 ,S 21 ,S 23 ,…,S 2n At these two moments, any satellite selected from S1 or S2 will comply with the delay constraint. Further analysis shows that there is a common part in S1 or S2, namely Figure 7 For the nodes represented by green in the figure, these common satellites can meet the latency requirements of the computing tasks during the period [t0, t0+τ, and there is no need to migrate the tasks when the latest satellite changes.

[0168] Therefore, this migration path selection problem can be redefined as an optimization problem: within a specified time period [t0, t0+ΔT], assuming that there is a set of candidate satellites S1, S2, …, S1 sorted by distance. N , each set S i The elements in may not be unique. The goal is to select a satellite from each set Si to form a sequence X = {x1, x2, x3, ..., x N}, where x i Representative from S i The selected satellite. If the adjacent elements x in the sequence X i and xi+1 are the same, then the pair of elements can be considered the same and merged to simplify the sequence. The core purpose of the optimization is to reduce the length of the merged sequence to the shortest. This optimization problem can be solved by the dynamic programming method, and the pseudo code of its solution strategy is described in Algorithm 2.

[0169]

[0170]

[0171] In this algorithm, the state dp[i][j] represents the shortest length of the merged sequence when the first i sets are processed and the element selected in the i-th set is j. The state transition is divided into two cases (see lines 11 to 23 of the algorithm code). The first case: if j is the same as the previously selected element (i.e., k in dp[i-1][k]), then dp[i][j] = dp[i-1][k], because repeated elements can be merged and will not increase the sequence length. The second case: if j is different from k, then dp[i][j] = dp[i-1][k] + 1, indicating that the newly added different elements increase the sequence length by 1. In this way, the complete dp table can be filled, where dp[n-1][min] stores the shortest sequence length, n is the number of sets, and dp[n-1][min] is the minimum value in the dp[n-1] list. At the same time, a choice array is used to track which k of dp[i-1][k] dp[i][j] is transferred from. Next, by backtracking from dp[n-1][min] to dp[0][x] (lines 34 to 40), the shortest sequence can be constructed in reverse. The shortest sequence finally obtained in this process is the ideal migration path for online streaming computing tasks that meet the latency constraints.

[0172] 2.2 Pre-migration mechanism of stateful computation graph

[0173] According to the migration path selection strategy mentioned above, the migration trajectory of computing tasks can be planned in advance. Based on this planning, this study divides the satellites on the migration path into three stages: service stage, warm-up stage and waiting stage. Fig.10 exhibit.

[0174] Using the state pre-migration mechanism, in the method designed by the present invention, the satellite in the service phase will create snapshots of the computation graph state when performing computation tasks, and transmit these snapshots to the nodes in the warm-up phase in advance. On these warm-up nodes, the received state snapshots are used to build new computation graphs, and data synchronization between the old and new computation graphs is achieved. The framework of this process is as follows: Fig.11 shown.

[0175] The pre-migration mechanism consists of the following four parts:

[0176] (1) At time t1, the access satellite sends a snapshot creation instruction to the service phase satellite according to the event control strategy based on data flow. After receiving this request, the service phase satellite node starts to create a snapshot of the stateful computation graph.

[0177] (2) After the snapshot is completed, the service node transmits the snapshot data to the preheating node. The preheating node uses this data and the execution information of the streaming task to build a new computational graph. This process corresponds to Fig.11 The period from t1 to t2.

[0178] (3) From time t2 until the migration operation is triggered, the access satellite sends the data stream to the old computation graph in the service phase and the new computation graph in the warm-up phase at the same time, ensuring that the data received by the new computation graph starts from the snapshot breakpoint.

[0179] (4) At time t3, the migration operation is triggered, the access satellite is replaced, and the preheated node becomes the new service node. The original access satellite continues to use cached data to synchronize to the new computation graph. At the same time, the new access satellite only sends data to the new service node. These new data are cached until the new computation graph finishes processing the old data and then starts processing the new data.

[0180] (IV) System design and implementation

[0181] 1. Overall architecture design of the system

[0182] The system of the present invention is named SatWeave, and its architecture is as follows Fig.12 As shown, the whole can be divided into satellite side components and satellite node side components.

[0183] The client component enables users to interact with the system through a visual interface, including two subsystems: mission management and onboard resource overview. These components support the creation and submission of missions, as well as the visual monitoring of satellites and mission resources within the constellation, respectively.

[0184] Satellite node components are compiled into static binary programs, deployed and run on the physical nodes of the satellite, and act as background services for the computing nodes. These components are divided into five levels according to their functions:

[0185] (1) Service Layer

[0186] The service layer acts as an intermediary between the client and the satellite nodes, providing interfaces for obtaining node information, submitting geographically independent tasks and streaming tasks. Through these interfaces, the client components can submit tasks and exchange information with the satellite nodes.

[0187] (2) Consensus layer

[0188] The consensus layer ensures that the task metadata and cluster status information of the nodes in the satellite cluster are consistent, and builds a dynamic and scalable Raft cluster, which provides an implementation basis for the self-organization and collaboration mechanism of the decentralized satellite cluster proposed in this paper. In addition, the consensus layer monitors changes in node status, updates cluster status information, and manages the dynamic joining and exiting of nodes, which is crucial for the long-term stable operation of the low-orbit satellite cluster.

[0189] (3) Geographically independent task processing layer

[0190] The geographically independent task processing layer is mainly responsible for scheduling and processing geographically independent tasks within the cluster. This layer allocates tasks by adjusting the task consensus set of the consensus layer, and establishes a task queue on each node based on the task metadata provided by the consensus layer. Tasks are processed in a containerized manner, and the calculation results are returned after completion.

[0191] (4) Stream computing task processing layer

[0192] The streaming computing task processing layer is responsible for parsing the streaming computing task description submitted by the client, and arranging operators based on the data flow relationship between operators to create and execute streaming computing tasks. As mentioned above, these streaming computing tasks are geographically sensitive online tasks in the satellite edge computing project. Therefore, this layer also implements the migration strategy proposed in the present invention to migrate streaming computing tasks.

[0193] (5) Infrastructure layer

[0194] The infrastructure layer provides the underlying operating environment for satellite computing nodes, covering container runtime, storage system, ephemeris calculation and operator library, etc. It supports the consensus layer, geographical location-independent task processing layer and streaming computing task processing layer, and provides storage capacity, container execution function, operator execution environment and ephemeris information.

[0195] On the satellite nodes, components collaborate with each other through remote procedure calls (RPCs) to build an autonomous low-orbit satellite cluster. The following sections will introduce the implementation details of the key modules of the SatWeave system.

[0196] 1. Raft consensus and information storage module implementation

[0197] 1.1 Raft Protocol Implementation Basics

[0198] The overall architecture of the Raft consensus and storage module is as follows Fig.13 shown.

[0199] The present invention uses Etcd-Raft Lib provided by Etcd to encapsulate and implement the system bottom layer of the Raft protocol. Etcd-Raft Lib includes the implementation of the core algorithm of the Raft protocol, but requires developers to supplement the functions of cluster member changes, inter-node communication, data storage and snapshots. Through the node structure, developers can implement the required interface to interact with Etcd-Raft Lib. The information consensus core module developed in the present invention further encapsulates the node structure and creates a RaftNode structure, whose data structure is shown in Table 6.

[0200] Table 6 Data structure of RaftNode structure

[0201]

[0202] Each satellite node runs a gRPC server, which is responsible for receiving information consensus requests within the cluster. These requests are divided into two categories: ordinary information consensus requests and configuration member change requests, which are used to achieve consistency in cluster state machine storage and modify node configurations in the Raft algorithm, respectively. The gRPC service sends these requests to RaftNode for processing through the proposeC and confChangeC channels. After receiving the request, RaftNode calls the Propose or ProposeConfChange method of Etcd-Raft Lib through its node member according to the request type. Etcd-Raft Lib communicates with other nodes in the cluster through the Raft protocol process. Once the log information is consistent, the applicable log information is sent to the upper layer through the readyc channel. Subsequently, RaftNode interacts with the storage module's coroutine through the commitC channel to complete the storage of consensus information.

[0203] In addition, to prevent the excessive accumulation of consensus log data in the Raft protocol, this study also introduces a snapshot module. RaftNode uses the snapshot module to take a snapshot of the current storage state. After creating a snapshot, the original Raft log information can be greatly compressed to save storage space.

[0204] 1.2 Raft protocol communication and storage interface

[0205] Etcd-Raft Lib only implements the core behavior of the Raft protocol, and does not yet cover the message transmission function and state machine storage capacity of the network layer. Therefore, the invention further implements the Raft network communication interface and the state machine storage interface.

[0206] (1) Implementation of Raft communication interface

[0207] In the implementation of the Raft algorithm, ensuring effective communication between cluster nodes is the key, including: heartbeat maintenance, log update, member change, election initiation and voting and other important operations. In order to achieve this goal, the present invention creates a Message structure, as shown in Table 7, to encapsulate these different types of messages. The Message structure contains necessary fields, such as message type, target node identifier, etc., to ensure that the message can be correctly processed and forwarded to the corresponding node. This encapsulation method simplifies the message processing logic, making communication between nodes more efficient and reliable.

[0208] The invention implements the transmission mechanism of Raft algorithm messages between nodes through the gRPC framework. The interaction between the upper-level application and RaftNode is realized through a channel called raftChan. When the upper-level application detects information from raftChan, it parses the message contained in the Message structure, especially identifying the node to which the message should be sent based on the "To" field. Subsequently, the message is sent to the specified node using the SendByRpc method developed by the present invention. The receiving node obtains the message through the gRPC interface and forwards it to RaftNode through the raftChan channel, completing the processing flow of the Raft message. The process is as follows Fig.14 shown.

[0209] Table 7 Main members and meanings of the Message structure

[0210]

[0211] (2) Implementation of storage interface

[0212] The Raft algorithm can synchronize the application states in the upper state machine by executing log entries in sequence. In order to synchronize the mission information between satellites, we further implement a state machine dedicated to storing mission information based on the Raft protocol.

[0213] The process of interaction between RaftNode and storage module is similar to the communication interface mentioned above. Fig.12 The RaftNode shown includes a channel called commitC, which is used to apply these log entries to the storage state machine when the message synchronization proposal of the Raft algorithm is supported by the majority of nodes. These pending entries will be passed through the commitC channel. The storage module developed by the present invention receives the Commit message structure through a goroutine that continuously monitors the commitC channel. The structure contains three types of operations, as shown in Table 8. After receiving these messages, the storage module will update the storage state machine according to the operation type and data content.

[0214] Table 8 Data operation types in Commit message

[0215]

[0216] The process of interaction between RaftNode and storage module is similar to the communication interface mentioned above. Fig.12 The RaftNode shown includes a channel called commitC, which is used to apply these log entries to the storage state machine when the message synchronization proposal of the Raft algorithm is supported by the majority of nodes. These pending entries will be passed through the commitC channel. The storage module developed by the present invention receives the Commit message structure through a goroutine that continuously monitors the commitC channel. The structure contains three types of operations, as shown in Table 8. After receiving these messages, the storage module will update the storage state machine according to the operation type and data content.

[0217] The present invention constructs a Storage interface to provide a state machine storage service. The interface definition includes a set of methods for reading and storing state machine data. The methods that the interface needs to implement are shown in Table 9, which promotes the scalability of the system. Developers can customize and implement specific storage solutions according to different application scenario requirements. In actual use, the present invention proposes two storage implementations: MemoryStorage and RocksdbStorage. MemoryStorage relies on memory and is suitable for use in development and testing environments; RocksdbStorage is based on the Rocksdb database and is suitable for deployment in production environments.

[0218] Table 9 Methods that the Storage interface needs to implement

[0219]

[0220] 2. Node status monitoring and cluster member change module implementation

[0221] The node status monitoring and cluster member change module is the key to ensure satellite self-organization and cluster high availability. It mainly monitors the health of nodes, and redistributes tasks and updates the Raft cluster member configuration when a faulty node is found. This ensures that the tasks running in the cluster can be reliably guaranteed, and can quickly and effectively restore the cluster status when a node has a problem, maintaining stability and availability. The module architecture is as follows Fig.15 shown.

[0222] 2.1 Implementation of node status monitoring

[0223] In this system, each node is equipped with a real-time status monitoring component (Monitor) to monitor the current status of the node. Its monitoring indicators are shown in Table 10. This component also continuously verifies whether it is the leader of the Raft cluster. Once it is determined to be the leader, it will periodically send status check requests to the monitoring components of other nodes in the cluster to track the health of each node in the cluster. If any node fails to respond to its status within the set monitoring period, the system will identify the node as a failed node and automatically trigger the corresponding fault recovery mechanism.

[0224] Table 10 Collection indicators of monitoring collector

[0225]

[0226] 2.2 Implementation of cluster member changes

[0227] The cluster member changes in the system are triggered by two events: the periodic reorganization mechanism proposed in this invention and the node status monitoring finding a node abnormality. Periodic reorganization includes not only the node joining a new cluster, but also its exit from the old cluster. However, the node status monitoring finding an abnormality only triggers the node exit process, and the node exit process is part of the joining and exiting process. Therefore, the following will take the periodic reorganization mechanism as an example to explain the cluster member change process in detail, where Fig.16 A timing diagram showing the recombination mechanism.

[0228] 1. The node sends a request to the leader of the new cluster to join the cluster.

[0229] 2. The new cluster leader that receives the SatNode request will initiate a consistency request to other members of the cluster and update the cluster information through the ProposeInfo method.

[0230] 3. Once more than half of the nodes agree to the update, the new cluster leader requests the raftNode module to change the member configuration through the ProposeConfChange method. This change is transmitted to the consensus core module of all nodes in the cluster through the network layer, and each node collaborates to complete the update of the Raft cluster member configuration. After completion, it confirms to SatNode that it has successfully joined the new cluster.

[0231] 4. After joining the new cluster, SatNode requests the leader of the original cluster to exit the cluster.

[0232] 5. After receiving the exit request, the original cluster leader also issues a consistency request to other cluster members through the ProposeInfo method to update the cluster information.

[0233] 6. The process is similar to the steps when joining a new cluster. After more than half of the nodes agree, the original cluster leader will initiate a configuration change to the raftNode module through the ProposeConfChange method. This process is the same as the operation in step 4.

[0234] resemblance

[0235] 3. Stream computing orchestration and startup module implementation

[0236] 3.1 Basic Structure of Operators and Subtasks

[0237] The invention implements the transmission mechanism of Raft algorithm messages between nodes through the gRPC framework. The interaction between the upper-level application and RaftNode is realized through a channel called raftChan. When the upper-level application detects information from raftChan, it parses the message contained in the Message structure, especially identifying the node to which the message should be sent based on the "To" field. Subsequently, the message is sent to the specified node using the SendByRpc method developed by the present invention. The receiving node obtains the message through the gRPC interface and forwards it to RaftNode through the raftChan channel, completing the processing flow of the Raft message. The process is as follows Fig.13 shown.

[0238] This invention proposes a mechanism called OperatorFactory for managing and registering operators. Developers need to implement the OperatorBase interface to register new operators and make them available. The OperatorBase interface defines a series of methods that must be implemented as shown in Table 11.

[0239] Inside the system, each operator is encapsulated in a structure called SubTask to instantiate the operator. To improve the concurrency of the system, each SubTask instance runs in a separate goroutine. The definition of the SubTask structure is shown in Table 12.

[0240] Table 11 Methods that operators in the system need to implement

[0241]

[0242] 3.2 Scheduling and starting process of streaming computing tasks

[0243] The present invention allows users to define streaming computing tasks using a low-code method by dragging and dropping on the front-end interface. The orchestration and startup process of streaming computing tasks is shown in detail in Fig.17 in the timing diagram.

[0244] 1. The user creates a directed acyclic graph (DAG) of a streaming computing task by dragging and dropping on the front-end service interface, and obtains a Json-format description of the task DAG from the front-end.

[0245] 2. Next, the user submits the DAG description information of the streaming computing task to the process orchestration service. This service creates a SubTask structure based on the Json description and establishes the upstream and downstream relationships between these SubTasks to form an actual execution graph.

[0246] 3. The process orchestration service then sends this execution graph (SubTask list) to the cluster leader node where the satellite node that executes the task is located to initiate the task execution request.

[0247] 4. To ensure that all downstream subtasks are started, the cluster leader node uses a depth-first search method to start the SubTasks one by one. When all SubTasks are started, the task start completion response will be returned.

[0248] 5. After completing these steps, the process orchestration service returns the task status information to the user, and the user can now start interacting with the streaming computing task.

[0249] 4. Data flow and event control module implementation

[0250] The data flow and event control module plays a key role in the execution of onboard streaming computing tasks. It is responsible for data exchange between subtasks and handles events such as computational graph snapshots and computation stop. Fig.18 A structural diagram of this module is presented.

[0251] 4.1 Data and event distribution receiving components

[0252] Fig.17 The data receiving component (Dispatcher) and the data distribution component (Receiver) constitute the core of communication and realize the data flow between subtasks. The data distribution component is responsible for passing the data and events generated by the upstream subtask to the downstream subtask according to the physical execution graph. The data receiving component is responsible for receiving this data and forwarding it to the corresponding subtask through the channel. When there are multiple upstream subtasks, the data receiving component will also synchronize different data streams when processing data stream snapshot events to ensure data consistency.

[0253] 4.2 Data and Event Processing Mode

[0254] 4.1 describes the core operating principle of the data flow and event control module, and regards the event and data processing functions as the processing layer. The data receiving and data distribution components act as the intermediary layer, coordinating the message transmission between the network communication layer and the processing layer, and are responsible for encapsulating and distributing data and control information respectively.

[0255] The processing layer implements multiplexing through channels and receives records from the data receiving component, as defined in Table 12. The dataType field in the record is used to distinguish between data and event types. Based on this field, the processing layer deserializes the data byte array to obtain the specific content. In particular, when dataType is Checkpoint, it indicates that the record is a snapshot event. For subtasks connected to multiple upstream operators, the data receiving component will suspend subsequent data processing until the snapshot events of all upstream operators are received. Only then will the event processing layer process the snapshot signal to ensure that the progress of the data streams of each partition is consistent at the time of the snapshot. After the data processing is completed, the processing result is sent to the data distribution component in the form of a byte array, which then encapsulates it into the data field of the Record and sends the record to the corresponding data partition of its data receiving component according to the downstream subtask Endpoint through RPC calls. The data receiving component of the downstream subtask then reads data from the partition.

[0256] Table 12 Main members and meanings of Record structure

[0257]

[0258] 5. Implementation of streaming computing task migration module

[0259] 5.1 Snapshotting of Stateful Computational Graphs

[0260] In streaming computing applications of low-orbit satellites, computing tasks usually include multiple operators, forming a computational graph. The SatWeave system allocates a thread to each operator to enhance concurrent processing capabilities. For stateful computational graphs, a snapshot of the computational graph state must be created before performing migration. Based on the data flow control mechanism and the asynchronous barrier-based snapshot algorithm introduced in Section 4.1, the present invention implements the global snapshot of the states of each operator in the computational graph, where the specific steps of the snapshot process are shown in Fig.19 in the flow chart.

[0261] 5.2 Migration Implementation of Stateful Computational Graph

[0262] This module consists of migration event listeners, snapshot creators, snapshot transfers and loaders, and data synchronizers, which interact with each other through Fig. 20 The schematic diagram in is shown.

[0263] The main function of the migration event listening component is to trigger the migration event of the computing task and add the snapshot creation signal to the data stream. When the stateful operator receives this signal, it will convert its computing state into binary form. After the snapshot is completed, the snapshot transmission and loading component is responsible for transmitting the state snapshot of the computation graph to the destination node. The details of the structure of the computation graph state snapshot (StateSnapshot) are shown in Table 13.

[0264] Table 13 Main members and meanings of the StateSnapshot structure

[0265]

[0266] The definition of the StateSnapshot structure uses Protobuf and is transmitted in serialized form. After receiving the snapshot, the target node will rebuild the calculation graph and use the operator name to extract the calculation state of the specific operator from the stateContent field in the StateSnapshot, and deserialize it to load the state. The node will also adjust its nextProcessedDataId field to lastProcessedDataId plus one. At the same time, the original migration node starts a thread to forward the data records received after the snapshot to the target node. These records are temporarily stored in a buffer queue. After the state is loaded, they are processed one by one and the nextProcessedDataId is refreshed. For newly received data records, if the dataId is inconsistent with the nextProcessedDataId, they will also be cached until the new calculation graph state catches up with the state at the time of migration. At this time, the original node stops forwarding data, and the new node starts processing the migrated data to ensure that the streaming calculation follows the "exactly once" semantics.

[0267] Although some embodiments of the present disclosure have been shown and described, it will be appreciated by those skilled in the art that modifications may be made to the embodiments without departing from the principles and spirit of the present disclosure, the scope of which is defined by the claims and their equivalents.

Claims

1. An autonomous on-orbit computing system for low-orbit satellites, characterized in that: Manage the satellite system by dividing the satellites in the constellation into multiple autonomous groups, build a unified management mechanism and an intra-autonomous group management mechanism to build a management system for the satellite autonomous group, and build a geographically sensitive streaming computing task migration solution to build an optimization solution for the satellite system's ground communication; The unified management mechanism implements node management and task allocation within the autonomous group for satellite nodes in the low-pass satellite constellation by constructing a load-aware satellite autonomous group dynamic partitioning strategy, and uniformly manages the satellite nodes; The autonomous group management mechanism determines the grouping of satellite constellations and constructs a decentralized satellite cluster self-organization and collaboration mechanism to organize and manage the autonomous group, so as to take into account the needs of satellite automatic grouping strategy and the dynamic changes of node online and offline status to deal with key node failures; The geographically-sensitive streaming computing task migration solution migrates computing tasks by optimizing migration path selection and streaming computing task migration strategies, thereby reducing the frequency and cost of online streaming computing task migration and shortening service interruption time caused by migration.

2. The on-orbit computing autonomous system for low-orbit satellites according to claim 1, characterized in that: The load-aware satellite autonomous group dynamic division strategy is constructed by considering the satellite load conditions at different time and space positions to divide the groups. First, the satellite load index is modeled based on the existing geographic device density index data and the traffic ratio changes throughout the day to define the future real-time load of the satellite. Then, a dynamic satellite grouping mechanism using spatiotemporal load prediction is designed to predict the load conditions of each satellite in the next certain period of time, and pair high-load satellites with low-load satellites to achieve dynamic grouping adjustment. The implementation method of the dynamic satellite grouping mechanism using spatiotemporal load prediction is as follows: for a low-orbit satellite constellation, the satellite sub-satellite point trajectory coordinates are obtained through the SGP algorithm, and the satellite sub-satellite point trajectory coordinates, the ground area equipment static density index, and the real-time traffic ratio distribution are input into a load calculation unit. The load calculation unit predicts the future real-time load of the satellite through the input data to calculate the average load index in the future time period, and generates satellite groups through a grouping algorithm.

3. The on-orbit computing autonomous system for low-orbit satellites as claimed in claim 2, characterized in that: The specific method of modeling is: the load index L of satellite i at time T i (T): L i (T) = D (Lat i (T),Lon i (T))×F(G(Lat i (T))), where D(Lat i ,Lon i ) represents coordinates (Lat i ,Lon i ) corresponding to the static density index of the device, Lat i (T) and Lon i (T) respectively represent the longitude and latitude of the subsatellite point coordinates of satellite i at time T, F(t) is the flow ratio corresponding to the time zone t corresponding to the subsatellite point trajectory of the satellite within a day, G(Lat i (T)) represents the time zone time t calculated based on longitude and UTC time T; The method for obtaining the average load index in the future time period is as follows: a low-orbit satellite constellation consisting of N satellite nodes is set, and the set of satellite nodes of this constellation is represented as S, that is, S = {s1, s2, s3, ..., s N-1 ,s N }, each element in the set represents a separate satellite node; then define the satellite node s i The average load index from the start time t0 to the future time period t0+ΔT m represents the number of samplings, and t0 is the time point when sampling starts; The standard deviation of the average load index between groups is used as the evaluation indicator. i , the group contains n satellites, represented as a set {s i1 ,s i2 ,…,s in }, at time T, the average load index Load of the group is used avg (cluster i ) represents the average value of all satellite load indices in the group: The process of generating satellite groups by using the grouping algorithm is as follows: using a genetic algorithm to minimize the standard deviation of the average load index of each group.

4. The on-orbit computing autonomous system for low-orbit satellites according to claim 1, characterized in that: The specific content of the decentralized satellite cluster self-organization and collaboration mechanism is as follows: construct a satellite cluster collaboration model based on peer nodes, set up a leadership node, called the Leader node, to serve as the management center of the cluster, and other nodes except the Leader node are called Follower nodes, which serve as the submission, distribution and processing mechanism of satellite grouping tasks, and build an information consistency guarantee mechanism to keep the task consensus information and satellite grouping information updated and accurate. On this basis, a dynamic self-organization mechanism of satellite nodes is constructed as a dynamic selection mechanism of the leader node, thereby forming a self-organization and collaboration mechanism of the satellite cluster.

5. The on-orbit computing autonomous system for low-orbit satellites as claimed in claim 4, characterized in that: The logic of the satellite cluster collaboration model based on peer nodes is that the ground-end devices submit tasks to the access point satellites closest to them, and transmit metadata descriptions of the computing tasks and file data required for task execution during the task submission process; After receiving the file data required for calculation, the access satellite will adopt a multi-copy strategy, and the file data is stored on several fixed nodes in the group to which it belongs; Next, the access satellite integrates the file path information corresponding to the task into the metadata description of the task, and forwards the updated metadata information to the leader node of the group to which it belongs; the distributed task consensus set mechanism is used as the information consistency guarantee mechanism, and the Raft algorithm is applied to maintain the consistency of information and record the task metadata within the cluster. When the leader node receives the new task metadata, it refers to the distributed task consensus set and selects the node suitable for executing the task based on the current load of the nodes in the group. After the selection is completed, the leader node updates the details of the execution node to the corresponding field in the task metadata, and further adds the updated task information to the distributed task consensus set; Finally, the nodes in the autonomous group regularly check the task information in the distributed task consensus set. If they find that the node ID specified by the task is consistent with their own ID, they will add the task to their own queue for processing. After the task is processed, the relevant task will be removed from the task set.

6. The on-orbit computing autonomous system for low-orbit satellites as claimed in claim 5, characterized in that: The dynamic self-organizing mechanism of the satellite nodes is realized through the dynamic construction process of the satellite autonomous group and the offline state detection and processing mechanism of the satellite nodes; The dynamic construction process of the satellite autonomous group is as follows: when the current leader node encounters a problem, a certain node A will trigger the regrouping mechanism at a fixed time, update itself to the "unschedulable" state in the cluster state consensus table to enter the regrouping state, and apply to other group members to be the leader; if the current cluster has no leader, then node A will automatically become the new leader node and process requests from other nodes to join the cluster; if the cluster already has a leader node, there are two situations: if the ID of the current leader node is larger than that of node A, then the current leader node only needs to include node A in the Raft configuration. On the contrary, if the ID of the current leader node is smaller than that of node A, then after adding node A to the Raft configuration, the current leader node needs to start the leadership transfer process and hand over the leadership node position to node A; The satellite node offline status detection and processing mechanism includes three parts: offline node detection mechanism, offline node task migration, analysis of the impact of node offline on cluster availability and solutions. The specific process of the offline node detection mechanism is as follows: the leader node periodically sends heartbeat signals to other nodes. When the follower node receives the heartbeat signal of the leader node, it feeds back its survival status to the leader. If a follower node does not respond to the leader's heartbeat within a specified number of times, the leader will regard it as an offline node and trigger the task migration mechanism of the corresponding offline node. The task migration mechanism of the offline node is as follows: when the leader node identifies that a follower node in the cluster is offline, it obtains the details of the pending tasks on the offline node, and then, by applying a load balancing method, the leader node reallocates these tasks to other online nodes in the cluster; The impact of node offline on cluster availability and the solution are as follows: The Leader node triggers the Raft member configuration adjustment program, removes offline nodes from the Raft cluster configuration, and updates cluster member information.

7. The on-orbit computing autonomous system for low-orbit satellites according to claim 1, characterized in that: The geographically sensitive streaming computing task migration scheme first constructs a migration path selection strategy based on delay constraints to reduce the number of migrations, and recommends that the ground terminal select the nearest satellite as the access point to minimize the delay from the ground to the access satellite; Finally, a pre-migration mechanism for stateful computational graphs is designed to achieve task migration through four steps.

8. The on-orbit computing autonomous system for low-orbit satellites as claimed in claim 7, characterized in that: The pre-migration mechanism of the stateful computation graph specifically includes: Step 1: The access satellite sends a snapshot creation instruction to the satellite in the service phase according to the event control strategy based on data flow. After receiving this request, the satellite node in the service phase starts to create a snapshot of the stateful computation graph; Step 2: After the snapshot is completed, the service node transmits the snapshot data to the preheating node, and the preheating node uses this data and the execution information of the streaming task to build a new calculation graph; Step 3: From the moment the second node is entered until the migration operation is triggered, the access satellite sends the data stream to both the old computation graph in the service phase and the new computation graph in the warm-up phase; Step 4: When the input reaches the migration destination node, the migration operation is triggered, the access satellite is replaced, the preheated node becomes the new service node, and the original access satellite continues to use the cached data to synchronize to the new calculation graph. At the same time, the new access satellite only sends data to the new service node. The new data is cached until the new calculation graph finishes processing the old data before starting to process the new data.

9. An on-orbit computing autonomous system for low-orbit satellites, characterized in that: An on-orbit computing autonomous system architecture for a low-orbit satellite, used to carry an on-orbit computing autonomous system for a low-orbit satellite as described in any one of claims 1-7, and its specific architecture includes: Service layer: acts as an intermediary between the client and satellite nodes, providing interfaces for obtaining node information, submitting geographically independent tasks and streaming tasks; Consensus layer: builds a dynamic and scalable Raft cluster, monitors changes in node status, updates cluster status information, and manages the dynamic joining and exit of nodes; Geographically independent task processing layer: schedules and processes geographically independent tasks within the cluster, allocates tasks by adjusting the task consensus set of the consensus layer, and establishes a task queue on each node based on the task metadata provided by the consensus layer. Tasks are processed in a containerized manner and the calculation results are returned after completion. Stream computing task processing layer: parses the streaming computing task description submitted by the client, and arranges operators based on the data flow relationship between operators to create and execute streaming computing tasks, and implements the geographical location-sensitive streaming computing task migration solution strategy proposed in the present invention; Infrastructure layer: provides the underlying operating environment for satellite computing nodes, covering container runtime, storage system, ephemeris calculation and operator library, supports consensus layer, geographical location-independent task processing layer and streaming computing task processing layer, provides storage capacity, container execution function, operator execution environment and ephemeris information.

10. The on-orbit computing autonomous system for low-orbit satellites according to claim 9, characterized in that: The construction of a dynamically scalable Raft cluster is achieved through a Raft consensus and information storage module with a dedicated architecture; monitoring changes in node status is achieved through a node status monitoring and cluster member change module with a dedicated architecture; the streaming computing task processing layer is achieved through a streaming computing orchestration and startup module with a dedicated architecture.

Images