Knowledge graph and user intent task decomposition method for satellite mission planning

Abstract

This invention provides a knowledge graph and user intent task decomposition method for satellite mission planning. Addressing the problems of existing knowledge storage methods leading to severe fragmentation of knowledge elements, existing remote sensing knowledge graph ontologies focusing on specific application contexts and failing to achieve multi-source heterogeneous data fusion, as well as poor scalability, the constructed knowledge graph divides entities into multiple functional libraries and relationships into intra-library entity relationships and inter-library entity relationships. This results in a massive network structure where entities within each functional library are closely connected, and entities between libraries also have close relationships, thus coupling the entire graph into a whole and achieving the fusion of multi-source heterogeneous data such as user needs and resource characteristics.

Description

Technical Field

[0001] This invention relates to the field of knowledge graph construction, and in particular to a knowledge graph and user intent task decomposition method for satellite mission planning. Background Technology

[0002] Remote sensing satellites, as a crucial means of acquiring space-based information, play a vital role in national land surveys, disaster monitoring, environmental protection, military reconnaissance, and accident rescue. With the rapid development of aerospace equipment, the number of Earth observation satellites in orbit in my country has increased rapidly, and the platform mobility, onboard computing power, and communication capabilities of these satellites have also made significant progress. Furthermore, the types and quantities of satellite resource demands from various users are becoming increasingly diverse, placing higher requirements on remote sensing products in terms of timeliness, accuracy, and other dimensions. How to fully utilize these satellite resources to maximize their effectiveness and meet the growing needs of users is an urgent problem that needs to be solved in the field of satellite mission planning.

[0003] Satellite mission planning encompasses user requirement submission, observation plan formulation, onboard command execution, and remote sensing data analysis. Its aim is to utilize limited satellite resources to arrange onboard observation plans and maximize user satisfaction. This involves elements such as objectives, resources, intentions, tasks, events, situations, rules, and algorithms, along with their complex interrelationships. In the current context, satellite users have broad preferences, complex needs, and numerous types of observation targets. Different types of observation targets exhibit significant differences in temporal, spatial, and frequency characteristics, necessitating consideration of the overall relationships between various elements during satellite mission planning. However, currently, these elements and related knowledge are largely stored in various documents and databases, increasing the difficulty of retrieval and leading to the breakdown of some coupling relationships and fragmented knowledge. This significantly increases the limitations of the satellite mission planning process and reduces the quality of planning results. Therefore, it is crucial to fully utilize existing satellite planning elements to quickly provide satellite mission planning elements tailored to user needs, thereby characterizing the relationships between elements without losing individual element attributes.

[0004] Since Google introduced the concept of knowledge graphs in 2012, knowledge graphs, as a representative technology of cognitive intelligence, an important branch of artificial intelligence, have played a crucial role in multiple fields such as semantic search, intelligent question answering, language understanding, and decision analysis. They have provided strong support for managing and analyzing large-scale, multi-source, heterogeneous data in satellite mission planning. Compared to relational databases, the directed graph knowledge modeling method of knowledge graphs gives them a significant advantage in representing, identifying, discovering, and reasoning about complex relationships between things. Compared to neural networks, knowledge graphs are no longer based on "black box" operations; their construction and application processes are highly interpretable, meeting the high requirements of interpretability in satellite mission planning. Therefore, choosing knowledge graphs as the modeling and storage tool for the attributes and relationships of satellite mission planning elements, establishing a domain knowledge graph for satellite mission planning, accurately grasping the intentions of different users, achieving reasonable scheduling of limited satellite resources, and effectively improving the automation and intelligence level of satellite mission planning.

[0005] An ontology of a knowledge graph characterizes the basic framework of a domain, providing explicit definitions of concepts, relationships, and attributes. Existing knowledge graphs applied in remote sensing are concentrated in water conservancy, geology, and environmental monitoring. These studies are all user-oriented knowledge graphs built for remote sensing targets within specific application contexts. Each ontology focuses only on representing the internal relationships between targets within that specific application context, without analyzing other satellite mission planning elements such as satellite resources. This results in limited scalability of the constructed knowledge graphs. Currently, no research in the field of satellite mission planning has proposed a reasonable ontology architecture to describe the internal attributes of various elements and their coupling relationships, hindering the fusion of multi-source heterogeneous data such as user needs and resource characteristics, and their subsequent applications. To address this issue, this paper aims to construct a reasonable domain knowledge graph ontology for satellite mission planning, defining the concept classes, relationship classes, and related attributes of each element within the domain. Due to the inherent subjectivity and limitations of ontology, different ontologies often exist even within a single domain. The ontology constructed in this paper aims to achieve maximum "consensus" in the satellite mission planning domain, maximizing the efficiency of knowledge sharing in satellite mission planning and making it more aligned with actual business operations. Summary of the Invention

[0006] The technical problem to be solved by this invention is how to construct a knowledge graph for satellite mission planning based on the elements of the satellite mission planning domain, and provide the corresponding observation elements required for the mission based on the observation intentions input by the user according to the knowledge graph.

[0007] To solve the above-mentioned technical problems, the technical solution adopted by the present invention is as follows:

[0008] A knowledge graph for satellite mission planning includes entities, relationships between entities, attributes of entities, and attribute values. The entities are divided into multiple functional libraries according to their functions. The relationships between entities are divided into intra-library entity relationships and inter-library entity relationships. Intra-library entity relationships describe the relationships between entities in the same functional library, while inter-library entity relationships describe the relationships between entities in different functional libraries.

[0009] Entity attributes are attributes that each entity possesses, and the attribute value is the specific value that the corresponding entity attribute can take.

[0010] Furthermore, the multiple functional libraries are respectively a target library, a resource library, a requirement library, an event library, and a rule library.

[0011] The target database stores data about satellite observation targets; each satellite observation target is treated as a physical node.

[0012] The resource repository stores observation, telemetry, tracking, and data transmission resources in the satellite mission planning; each resource is a physical node.

[0013] The requirement library models and stores user intents and the tasks decomposed from user intents; each user intent is treated as an entity node, and each task decomposed from the user intent is treated as an entity. An entity relationship is established between the task and the corresponding user intent before decomposition, and the task is attached to the corresponding user intent.

[0014] The event database manages data on routine or unexpected events in the field of satellite mission planning; each event is an entity.

[0015] The rule base stores the rules used in the satellite mission planning process; each rule is an entity node.

[0016] Furthermore, the targets in the target library are classified according to user needs, and the subclasses can be further divided. Entity attributes are defined on the lowest-level subclass with the most detailed subclass classification.

[0017] Furthermore, the target library classifies targets according to user needs, including target domain classification, military-civilian classification, regional classification, dynamic and static classification, and category classification. The category classification has the most detailed subclasses, and attribute definitions are performed on the lowest level subclasses of the category classification.

[0018] Furthermore, the resources in the resource library are classified according to user needs, and the subclasses can be further divided. Entity attributes are defined on the lowest-level subclass with the most detailed subclass classification.

[0019] Furthermore, the resource library classifies resources according to user needs, including resource domain classification, military and civilian classification, usage classification, and category classification. The category classification has the most detailed subclasses, and attribute definitions are performed on the lowest level subclasses of the category classification.

[0020] Furthermore, the user intents in the demand library mainly include general surveys, detailed investigations, searches, identifications, and tracking of three target categories: point targets, area targets, and moving targets. Each task after the user intent is decomposed is treated as an entity, and an intra-library relationship is established between it and the corresponding user intent before decomposition. It is attached to the corresponding user intent, and the attributes of the task entity after the user intent is decomposed are jointly determined by the intent category and the execution payload category.

[0021] Furthermore, the rule base mainly includes rules for satellite payload usage, rules for satellite usage, rules for resource recommendation, and rules for intention inference.

[0022] Furthermore, in the relationships between entities, the intra-library entity relationships only include "target library - target library", "resource library - resource library", "requirement library - requirement library", and "event library - event library"; the inter-library entity relationships include "target library - event library", "target library - requirement library", "resource library - requirement library", and "event library - requirement library".

[0023] This invention also provides a user intent task decomposition method. Based on the target location and intent category input by the user intent, a knowledge graph for satellite mission planning is used to query the correspondence between the target location and intent category, namely "target category matching" and "intent category matching". The queried target category and intent category are used to locate the "payload usage rule" node in the rule base to obtain the payload category used by the task under the user intent. The task attribute fields of the subordinate observation tasks of this user intent are filled according to the attributes of the "payload usage rule" node to form a formal observation task that is uploaded to the satellite for execution.

[0024] Furthermore, the formal observation task is established as an "observation task" node in the requirement library, and an in-library entity relationship is established with the intent category node of the user intent, and a relationship is established with the target entity node in the target library.

[0025] By adopting the above technical solution, the present invention has the following beneficial effects:

[0026] This invention provides a knowledge graph and user intent task decomposition method for satellite mission planning. Addressing the problems of severe fragmentation of knowledge elements due to existing knowledge storage methods, the limitations of current remote sensing knowledge graph ontologies which focus on specific application contexts and cannot achieve multi-source heterogeneous data fusion, and poor scalability, the constructed knowledge graph divides entities into five functional libraries: target library, resource library, demand library, event library, and rule library. Relationships are divided into intra-library entity relationships and inter-library entity relationships, resulting in a vast network structure. Not only are entities within each functional library closely connected, but there are also close connections between entities in different libraries, making the entire graph a cohesive whole. This enables the fusion of multi-source heterogeneous data such as user needs and resource characteristics.

[0027] Based on the constructed knowledge graph, and according to the input user intent and the relationships between entities, satellite payloads relevant to executing this user intent are identified. By considering the priority, frequency, reconnaissance time, minimum resolution, and minimum imaging quality fields under the corresponding intent payload usage rules, the detailed elements required for the observation task are smoothly supplemented. This allows for the generation of specific observation tasks without the need for dedicated personnel, enabling rapid uploading to the satellite for execution. Furthermore, the newly generated observation tasks are added to the requirement database, establishing relationships between the current intent, new tasks, and other entities, thereby expanding the knowledge graph. Attached Figure Description

[0028] Figure 1 This is the ontology architecture diagram of the knowledge graph of this invention;

[0029] Figure 2 This forms the basic structure of a knowledge graph.

[0030] Figure 3 This is a schematic diagram of a specific implementation of the target library;

[0031] Figure 4 This is a schematic diagram of a specific implementation of the resource library;

[0032] Figure 5 This is a schematic diagram illustrating a specific implementation of a task in the requirements library;

[0033] Figure 6 This is a schematic diagram of a specific implementation in the event library;

[0034] Figure 7 This is a schematic diagram of a specific implementation of intent decomposition based on knowledge graphs. Detailed Implementation

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

[0036] A knowledge graph for satellite mission planning includes entities, relationships between entities, attributes of entities, and attribute values. The entities are divided into multiple functional libraries according to their functions. The relationships between entities are divided into intra-library entity relationships and inter-library entity relationships. Intra-library entity relationships describe the relationships between entities in the same functional library, while inter-library entity relationships describe the relationships between entities in different functional libraries.

[0037] Entity attributes are attributes that each entity possesses, and the attribute value is the specific value that the corresponding entity attribute can take.

[0038] In this embodiment, the plurality of functional libraries are respectively a target library, a resource library, a requirement library, an event library, and a rule library.

[0039] The target database stores data about satellite observation targets; each satellite observation target is treated as a physical node.

[0040] The resource repository stores observation, telemetry, tracking, and data transmission resources in the satellite mission planning; each resource is a physical node.

[0041] The requirement library models and stores user intents and the tasks decomposed from user intents; each user intent is treated as an entity node, and each task decomposed from the user intent is treated as an entity. An entity relationship is established between the task and the corresponding user intent before decomposition, and the task is attached to the corresponding user intent.

[0042] The event database manages data on routine or unexpected events in the field of satellite mission planning; each event is an entity.

[0043] The rule base stores the rules used in the satellite mission planning process; each rule is an entity node.

[0044] The target library stores data for satellite observation targets; each satellite observation target is treated as an entity node. In this embodiment, the targets in the target library are categorized according to user needs, and these subcategories can be further subdivided. Entity attributes are defined at the lowest level of the subcategories with the most detailed subcategories. Specifically, the current target library categorizes targets according to user needs into target domain classification, military-civilian classification, regional classification, dynamic / static classification, and category classification. Each category classification has the most detailed subcategories, and attribute definitions are performed at the lowest level of each category classification.

[0045] • Target domain classification: land targets, sea targets, air targets, space targets, etc.;

[0046] • Military-civilian classification: military targets, civilian targets;

[0047] • Regional classification: Targets oriented towards a specific region;

[0048] • Classification by movement: stationary targets, moving targets;

[0049] • Classification of natural disaster susceptibility: targets susceptible to earthquakes, targets susceptible to floods, targets susceptible to fires, etc.;

[0050] Category classification: airports, ports, cities, schools, hospitals, government departments, factories, bridges, railways, highways, stations, satellite ground stations, oil and gas platforms, shipyards, thermal power plants, hydroelectric power plants, nuclear power plants, islands and reefs, rivers, sea areas, coastlines, straits, canals, lakes, forests, aircraft, ships, spacecraft, space stations, etc.

[0051] In this embodiment, the knowledge graph ontology is constructed by referring to RDFS (RDF Schema), unfolding step by step, mainly divided into three parts: ① defining concepts, determining superclasses and subclasses; ② defining relations, determining the starting and ending concept categories of relations; ③ defining the properties of relations and concepts, determining property value constraints. In this embodiment, relations specifically refer to the edges between entity nodes in the knowledge graph. "instanceOf" is introduced to indicate that an entity is an instance of a concept, and "subclassOf" is introduced to indicate that a subclass is a subset of a superclass. The basic structure of the knowledge graph is as follows: Figure 2 As shown.

[0052] Based on user needs, the above classification can be further subdivided into superclasses and subcategories. For example, the concept of "airplane" can be further divided into subcategories such as "passenger plane," "tanker plane," "transport plane," and "fighter jet." Figure 2As shown, in the knowledge graph, subclasses and superclasses are connected using "subclassOf". Classifying into a superclass or further subdividing into subclasses is to facilitate quick retrieval of corresponding entity nodes in later applications of the knowledge graph. To avoid conflicting and redundant definitions, attribute definitions are only given for the lowest-level subclasses in the "category classification," and attributes are not defined for subclasses under other classification perspectives. For example, if the concept of "airport" is no longer subdivided, then "airport" is called the lowest-level subclass in the "category classification," and the attributes of the "airport" category are defined; "land target," as a subclass under other classification perspectives, does not have its attributes defined. An entity's attributes should inherit from its lowest-level subclass. Taking the entity "an international airport" as an example, its lowest-level subclass is the concept of "airport," and it also belongs to the concept of "land target." If the "land target" attribute is defined repeatedly, it will lead to conflicting and redundant definitions of the entity's attributes. Therefore, the attributes of the entity "an international airport" should inherit from the attributes of the "airport" concept, uniquely connected using "instanceOf," and the entity is connected to other concepts using the corresponding classification perspective. The entity "an international airport" is represented in the knowledge graph using the subject-relationship-object triple, i.e., the SPO (Subject-Predicate-Object) triple. Figure 3 As shown, attribute constraints include constraints on the data type, value range, and unit type of attribute keys. For example, the attribute "area" has a floating-point data type, a value range greater than 0, and a unit type of km. 2 .

[0053] In this embodiment, the resource repository stores observation, telemetry, tracking, and command (TT&C) resources from satellite mission planning; each resource is treated as a physical node. In this embodiment, resources also need to be categorized from multiple perspectives based on user needs, and the rationality of the categorization directly affects the efficiency of resource recommendations. Currently, the resource repository categorizes resources from the following perspectives, but is not limited to the following concepts.

[0054] • Resource domain classification: space-based resources, ground-based resources, marine resources, airspace resources, etc.;

[0055] • Military-civilian classification: military resources, civilian resources;

[0056] • Classification by application: observation resources, telemetry and control resources, data transmission resources, etc.;

[0057] • Category classification: electronic payload, optical payload, radar payload, electronic satellite, optical satellite, radar satellite, communication satellite, satellite ground station, satellite communication vehicle, satellite communication ship, etc.

[0058] The above classification perspectives represent common resource classification angles. Based on user needs, resource classifications can be further refined to expand into other conceptual categories. For example, satellite resources can be further divided into low-Earth orbit (LEO), medium-Earth orbit (MEO), and high-Earth orbit (HEO) satellites according to their orbital altitude; into equatorial orbit, polar orbit, and inclined orbit satellites according to their orbital inclination; and some special orbital satellites can be separately classified as geostationary orbit satellites, sun-synchronous orbit satellites, etc. Even constellations, star clusters, and star groups can be used to classify specific satellite resources. The most detailed subclasses exist under each category, with attribute definitions at the lowest level of the subclasses. Taking "Gaofen-1 01 satellite" as an example, the SPO triples related to this entity are as follows: Figure 4 As shown, its lowest-level subclass is "Optical Satellite". While attributes like "Payload" and "Satellite Orbit" also fall under the category of satellite attributes, they also contain their own inherent attributes. "Payload" includes attributes such as payload type, operating mode, resolution, field of view (swath width), and band; "Satellite Orbit" includes attributes such as epoch time and orbital elements. Therefore, the nodes linking "Payload" and "Satellite Orbit" are modeled as entities, such as... Figure 4 The "payload" relationship between "Gaojing-1 01" and "Gaojing-1 01 - Pancolor" is a relationship between entities and is not subject to attribute processing.

[0059] In this embodiment, the requirement library models and stores user intentions and the tasks decomposed from those intentions. Each user intention is treated as an entity node, and each task decomposed from the user intention is treated as an entity. An intra-library entity relationship is established between each task and the corresponding user intention before decomposition, and each task is attached to the corresponding user intention. The user intentions in the requirement library mainly include general surveys, detailed investigations, searches, identifications, and tracking of three target categories: point targets, area targets, and moving targets. Each task decomposed from the user intention is treated as an entity, and an intra-library relationship is established between each task and the corresponding user intention before decomposition, and each task is attached to the corresponding user intention. The attributes of the task entities decomposed from the user intention are jointly determined by the intention category and the execution payload category. For example, when using a visible light satellite payload to perform point target general surveys and detailed investigations, the required resolution differs; the task resolution attribute is jointly determined by the intention category and the payload category.

[0060] The user intent categories include:

[0061] • Point target survey: Conduct single or periodic observations of point targets within the required time frame, relax the requirements for the resolution of the satellite payload, and use satellite payloads with lower resolution to perform subordinate sub-tasks;

[0062] • Detailed observation of point targets: Conduct single or periodic observations of point targets within the required time, and perform subordinate sub-tasks using high-resolution satellite payloads;

[0063] • Regional target search: A single, complete coverage of regional targets within the required time frame, ensuring that the entire regional target area is covered after the satellite observation strips are stitched together. If the purpose of regional target coverage is to search for and discover missing moving targets, then this intention has a high timeliness requirement. The resolution of the satellite payload used is essentially determined by the attributes (size, material, etc.) of the source target that triggers the regional target search.

[0064] • Point target identification: A single observation of a suspected or unknown point target is performed within the required time. Sub-tasks are executed using a high-resolution satellite payload. If the purpose of point target identification is to identify and confirm a suspected or unknown moving target, then this purpose has a high timeliness requirement.

[0065] Moving target tracking: This involves continuously or relay-style tracking and observation of moving targets within a required timeframe, while ensuring a certain satellite payload resolution. This objective has high timeliness requirements.

[0066] Each user-submitted intent, after being decomposed, generates a task entity attached to its respective intent concept. However, unlike the target and resource libraries, the requirement library cannot simply obtain the task entity's attributes by defining the attributes of the lowest-level subclasses. This is because the attribute fields of a task entity are jointly determined by its intent category and the execution payload category. For example, task entities under the same point target survey category, executed by optical payloads and radar payloads, require different attribute fields. Some attribute fields, such as timeliness, priority, and target latitude and longitude, are the same, but the payload uses specific attribute fields determined by the execution payload category. Taking "Task X" as an example, the SPO triple associated with this entity is as follows: Figure 5 As shown, the "Intent Category" of this task entity is "Detailed Observation of Point Targets," and the "Payload Category" is "Visible Light." The entity attributes determined by these two factors include "Minimum Resolution," "Observation Timeframe," "Download Timeframe," "Priority," "Frequency," and "Minimum Imaging Quality." The underlined parts indicate the relationships between this task entity and other entities, such as the "Executable Payload" relationship with the optical payload entity "Gaojing-1 01-Panchroma" in the resource library, and the "Observation Target" relationship with the airport entity "A Certain International Airport" in the target library. This further confirms that the various functional libraries are not isolated from each other; the connections between entities in their respective data layers make the various functional libraries logically a whole.

[0067] The event database manages data on routine or unexpected events in the field of satellite mission planning; each event is an entity.

[0068] Events are the direct cause of observation needs. Currently, the reporting of observation needs is mainly done manually, which leads to drawbacks such as time-consuming processes, missed needs, and lost optimal observation opportunities. For sudden events, ground-based responses are often delayed, making the intelligent generation of needs by satellites with autonomous capabilities particularly important. Therefore, it is necessary to rely on existing human experience and historical cases to mine and summarize relevant knowledge about intent reasoning, and realize an intelligent process from event (situation) to intent, assisting human decision-making and recommending and supplementing needs. To achieve the complex mapping from event (situation) to intent, a comprehensive event database is first needed. Due to the diversity of event types, each user should build its event database according to its own business. For example, the event concepts built by disaster prevention departments may include "earthquake outbreak," "fire outbreak," "flood outbreak," and "landslide / mudslide outbreak"; the event categories built by coast guard departments may include "illegal vessel escape," "illegal vessel loss," "suspicious vessel discovery," and "search and rescue of distressed vessels." The basic attributes of an event include information such as subject, object, time, location, and source. Taking "Event Y" under the concept of "loss of an illegal vessel" as an example, the SPO triple related to this entity is as follows: Figure 6 As shown in the figure, at a certain moment, "illegal vessel Z" was lost in a certain location in a certain sea area. The information about this event was obtained from the execution of "task X". The user triggered the intention of "area target search" based on "event Y".

[0069] The rule base stores the rules used in satellite mission planning; each rule is an entity node. The rule base mainly includes rules for satellite payload usage, satellite usage, resource recommendation rules, and intent inference rules. By graphically modeling the rules using SPO triples, each invocation process is clearly displayed, enhancing interpretability from input to output. Specific rules, as entities, are attached to corresponding rule concepts. Currently, rules are classified according to the following categories, but are not limited to these concepts.

[0070] Payload Usage Rules: The payload category is selected and payload parameters are set based on factors such as target category, intent category, and environmental conditions. Target and intent categories are described in the target and mission libraries, respectively. Environmental conditions mainly include illumination conditions (solar altitude angle, etc.), meteorological conditions (cloud cover, etc.), and electromagnetic conditions (electromagnetic interference, silence, etc.) during satellite observation. Payload categories and parameters are described in the resource library. Taking optical payloads as an example, their parameters mainly include operating mode, spatial resolution, field of view (swath width), and spectral band. During intent decomposition, the payload category is selected and payload parameters are set according to the payload usage rules. Then, during mission resource matching, payload entities that do not meet the requirements are excluded from the candidate set. Taking a detailed nighttime observation of a point target at an international airport as an example, visible light payloads are excluded according to the rule "visible light payloads are prohibited during nighttime observation." If a radar payload is selected, the minimum resolution is set to 2m according to the "parameter template for radar payloads executing airport-point target detailed observation intent." As a resource selection constraint, all radar payloads that cannot reach a resolution of 2m are excluded.

[0071] Satellite Usage Rules: Based on the satellite's design and operational status, usage constraints are considered during resource scheduling. These constraints are mainly divided into two categories: satellite capability constraints and satellite protection constraints. Satellite capability constraints are determined by the onboard hardware capabilities, including satellite attitude maneuvering capabilities (pitch angle range, roll angle range, yaw angle range, turn rate), maneuver transition time, power consumption constraints, and storage capacity constraints. Satellite protection constraints aim to prevent the satellite from overloading, including payload single-orbit execution times and times, payload single-day execution times and times, satellite single-orbit maneuver times and times, satellite single-day maneuver times and times, and satellite continuous maneuver times and times. The satellite usage rules primarily guide the scheduling of single-satellite observation windows, excluding scheduling schemes that do not meet the constraints.

[0072] Resource recommendation rules: Based on task characteristics and resource characteristics, matching is performed to recommend reasonable alternative resources for the current task. After intent decomposition, each task corresponds to a set of alternative resources for execution. Each resource in the set satisfies the load usage rules, but their fitness for executing tasks varies. Fitness is affected by various factors, such as the current task load of the resource and the time window conflict between the task to be assigned and the task already assigned. The resource recommendation rules recommend reasonable alternative resources for subsequent task scheduling consideration. The resource recommendation rules themselves can be simple heuristic rules, such as "recommend the resource with the lowest current task load" or "recommend the resource with the lowest current time window conflict," which can be directly graphically modeled and stored in the rule base; or other decision models can be introduced, such as "Bayesian decision model" or "Markov decision model." In supervised machine learning models, the task resource matching results in historical data can be used as label data to guide the decision model to discover hidden patterns and calculate the recommendation probability or fitness score of each alternative resource.

[0073] Intent reasoning rules: Based on event characteristics, infer the observation intent that the satellite should execute under the current circumstances. The reasoning rules complete the mapping from event to intent, specifically addressing the question of what intent the satellite should trigger in response to what event. Because the categories of triggerable intents are not singular, the intent reasoning rules are similar to resource recommendation rules, also requiring the resolution of a multi-factor decision problem. For simpler application scenarios, the reasoning rules can be represented as "If-then" conditional statements and graphically modeled and stored in a rule base. When a single condition (event) or multiple conditions (situation) are met, the event category corresponding to the condition is locked, and the corresponding intent is triggered based on the connected "triggering" relationship. For more complex application scenarios, neural networks can be introduced to represent events, incorporating a Markov decision model where the decision-maker is considered an Agent, the event as a State, the intent as an Action, and the intent's reward as a Reward. Reinforcement learning methods are used to train the Agent to maximize the expected reward. The above methods require users to reasonably model the Environment and define the Reward values ​​for various intents according to their own needs to train a superior decision-maker.

[0074] Relationships between entities are divided into intra-library entity relationships and inter-library entity relationships. Intra-library entity relationships describe the relationships between entities within the same functional library, while inter-library entity relationships describe the relationships between entities within different functional libraries. As a crucial component of knowledge graphs, inter-entity relationships are a key differentiator between knowledge graph capabilities and other databases. In this embodiment, inter-entity relationships can be categorized into intra-library entity relationships and inter-library entity relationships. Intra-library entity relationships include "target library—target library," "resource library—resource library," "requirement library—requirement library," and "event library—event library"; inter-library entity relationships include "target library—event library," "target library—requirement library," "resource library—requirement library," and "event library—requirement library."

[0075] Intra-library entity relationships:

[0076] "Target Repository - Target Repository": Entity relationships within the target repository primarily describe the connections between targets. Typical relationships include distance, location, subordination (e.g., a reef belonging to an archipelago), and co-occurrence (multiple targets appearing or acting together, such as equipment coordinated formations). Like entities, relationships require defined attributes. For example, if distance relationships in a graph were directly represented by numerical values, the graph would become cluttered as the number of target entities increases, making query reasoning more difficult. Therefore, distance relationships in the graph are represented as "distance," with an added attribute to record their corresponding numerical values. Entity relationships within the target repository are mainly used for observation requirement recommendations. For instance, when an abnormal event occurs at a target, the intent to observe it can be inferred, and based on user preferences, the intent to observe related targets can be recommended simultaneously.

[0077] "Resource Repository - Resource Repository": The entity relationships within the resource repository primarily describe the connections between resources. Typical relationships include payload relationships (e.g., satellite entities carrying payload entities), matching relationships (e.g., certain satellites must perform telemetry, tracking, and command (TT&C) data transmission at certain ground stations), and collaborative relationships (resources working together to complete complex tasks, such as high-Earth orbit satellite collaboration, electronic satellite guiding optical or radar satellite collaboration, and wide-swath satellite guiding high-resolution satellite collaboration). Entity relationships within the resource repository are mainly used for recommending observation resources. For example, when a satellite needs to perform an observation mission, it recommends matching ground stations to perform the TT&C and data transmission tasks.

[0078] "Requirement Base - Requirement Base": The entity relationships within the requirement base primarily describe the associations between intents and tasks, mainly including temporal and logical relationships. Temporal relationships refer to the constraint that tasks must be executed sequentially, while logical relationships refer to the relationships between tasks that are independent, dependent, or mutually exclusive. Entity relationships within the requirement base are mainly used for conflict resolution during task scheduling. For example, if two tasks are mutually exclusive, and one task is successfully scheduled, the other task must be deleted.

[0079] "Event Repository - Event Repository": The entity relationships within the event repository primarily describe the connections between events. Similar to the relationships between tasks, these relationships are also categorized into temporal and logical relationships, and are mainly used for requirement recommendation. For example, an earthquake may be accompanied by other secondary disasters such as mudslides. To ensure timely prevention and monitoring, it is necessary to combine the event map to recommend observation intentions for related events.

[0080] Inter-database entity relationships:

[0081] The "Target-Event Database" primarily comprises two relationships: "Subject" and "Object." The "Subject" describes the active party in an event and is indispensable; the "Object" describes the passive party in an event and is optional. This database relationship is used to uncover target behavioral preferences, predict the target's next action, recommend relevant observation needs, and promptly capture changes in target behavior.

[0082] • "Target Library - Requirement Library": This mainly contains the "Observation Target" relationship, which indicates that the observation target of a task entity is a target entity. The number of relationship edges can record the number of times a target is observed, and thus the user's level of importance to different targets can be analyzed. This can be used as one of the bases for users to classify the importance level of targets, and can also be used to recommend target observation requirements based on the level of importance.

[0083] • "Resource Repository - Demand Repository": This mainly includes the "Execution Load" relationship, which indicates that the execution load of a task entity is a resource entity. Similarly, the number of relation edges can record the number of times a resource is used, and thus the user's habitual use or satisfaction with different resources can be analyzed. This can be used as one of the bases for judging whether the use of different resources is balanced, and resources can also be recommended based on the degree of habitual use.

[0084] The "Event Library - Requirement Library" primarily includes two relationships: "Source Task" and "Trigger." A "Source Task" indicates that an event originates from the observation results of a specific task. For example, if event Y is discovered by analyzing remote sensing data from task X, then task X is considered the source task of event Y. A "Trigger" represents an observation intention triggered by an event, representing the mapping relationship from event to intention in intention reasoning. The "Event Library - Requirement Library" relationship clearly records the mutual conversion between events and requirements, enhancing the interpretability of the intention reasoning process.

[0085] Entity attributes are attributes that each entity possesses, and the attribute value is the specific attribute value corresponding to the entity attribute.

[0086] This invention also provides a user intent task decomposition method. Based on the target location and intent category input by the user intent, a knowledge graph for satellite mission planning is used to query the correspondence between the target location and intent category, namely "target category matching" and "intent category matching". The queried target category and intent category are used to locate the "payload usage rule" node in the rule base to obtain the payload category used by the task under the user intent. The task attribute fields of the subordinate observation tasks of this user intent are filled according to the attributes of the "payload usage rule" node to form a formal observation task that is uploaded to the satellite for execution.

[0087] In this embodiment, the formal observation task is established as an "observation task" node in the knowledge graph, and a relationship is established with the intent category node of the user intent and the target entity node in the target library.

[0088] like Figure 7 As shown, the user proposes the intent to "conduct a point target survey of a certain lake". After word segmentation, the target is clearly identified as "a certain lake", and the intent category is "point target survey". The corresponding target and intent nodes are located in the knowledge graph. The target category is located as "lake" based on "instanceOf". The "payload usage rules" node is located based on the relationship between "lake" and "point target survey" and the corresponding relationship between "target category matching" and "intent category matching". It is found that the "visible light" payload can execute the lake-point target survey intent. The priority, frequency, reconnaissance time, minimum resolution, minimum imaging quality and other fields of the subordinate observation tasks of this intent are filled in according to the attributes of the "payload usage rules" template node. The "observation task" node is established and an edge "instanceOf" is established with the "point target survey" node. The relationship "observation target" is established with the "a certain lake" node. Assuming that after filtering according to various conditions and constraints, the "Gaofen-4-visible light" payload entity is selected as the execution payload and the relationship "execution payload" is established with the "observation task" node. At the same time, the execution satellite entity is determined to be "Gaofen-4" based on the "payload" relationship. The above process completes the intent decomposition function, breaking down the top-level intent proposed by the user into specific observation tasks. Simultaneously, the new task entity is added to the requirement library, and the relationship between this task entity and other entities is established.

[0089] After analyzing the remote sensing images from this observation mission, the event "X River dam breach" was discovered. A "dam breach" node was established, with a relationship of "source task" established between it and the "observation mission" node, and a relationship of "subject" established between it and the "X River" node. Based on the event "dam breach" and the relationship "trigger," the intent node "detailed observation of point target" was located. The above process completes the intent reasoning function, mapping the event to a top-level intent. Simultaneously, the new event entity was added to the event database, and the relationship between this event entity and other entities was constructed.

[0090] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A knowledge graph for satellite mission planning, characterized in that, It includes entities, relationships between entities, entity attributes, and attribute values. The entities are divided into multiple functional libraries according to their functions. The relationships between entities are divided into intra-library entity relationships and inter-library entity relationships. Intra-library entity relationships describe the relationships between entities in the same functional library, while inter-library entity relationships describe the relationships between entities in different functional libraries. Entity attributes are attributes that each entity possesses, and the attribute value is the specific value that the corresponding entity attribute can take; The multiple functional libraries are respectively the target library, resource library, requirement library, event library, and rule library. The target database stores data about satellite observation targets. Each satellite observation target is treated as a physical node; The resource repository stores observation, telemetry, tracking, and data transmission resources in the satellite mission planning; each resource is a physical node. The requirement library models and stores user intents and the tasks decomposed from user intents. Each user intent is treated as an entity node, and each task decomposed from the user intent is treated as an entity. An in-library entity relationship is established between the task and the corresponding user intent before decomposition, and the task is attached to the corresponding user intent. The event database manages data on routine or unexpected events in the field of satellite mission planning; each event is an entity. The rule base stores the rules used in the satellite mission planning process; each rule is an entity node.

2. The knowledge graph according to claim 1, characterized in that, The target library categorizes targets according to user needs, and the subcategories can be further subdivided. Entity attributes are defined on the lowest-level subclass with the most detailed subclass classification.

3. The knowledge graph according to claim 2, characterized in that, The target library categorizes targets according to user needs, including target domain classification, military-civilian classification, regional classification, dynamic and static classification, and category classification. The category classification has the most detailed subclasses, and attribute definitions are performed on the lowest level subclasses of the category classification.

4. The knowledge graph according to claim 3, characterized in that, The resource library categorizes resources according to user needs, and the subcategories can be further subdivided. Entity attributes are defined on the lowest-level subclass with the most detailed subclass classification.

5. The knowledge graph according to claim 4, characterized in that, The resource library categorizes resources according to user needs, including resource domain classification, military-civilian classification, usage classification, and category classification. Each category classification has the most detailed subclasses, and attribute definitions are performed on the lowest-level subclasses of the category classification.

6. The knowledge graph according to claim 2, characterized in that, The user intents in the demand library mainly include general surveys, detailed investigations, searches, identifications, and tracking of three target categories: point targets, area targets, and moving targets. Each task after the user intent is decomposed is treated as an entity, and an intra-library relationship is established between it and the corresponding user intent before decomposition. It is attached to the corresponding user intent. The attributes of the task entity after the user intent is decomposed are jointly determined by the intent category and the execution payload category.

7. The knowledge graph according to claim 1, characterized in that, The rule base mainly includes rules for satellite payload usage, rules for satellite usage, rules for resource recommendation, and rules for intention inference.

8. The knowledge graph according to claim 1, characterized in that, Among the relationships between entities, the intra-library entity relationships only include "target library - target library", "resource library - resource library", "requirement library - requirement library", and "event library - event library"; the inter-library entity relationships include "target library - event library", "target library - requirement library", "resource library - requirement library", and "event library - requirement library".

9. A user intent task decomposition method, using a knowledge graph for satellite mission planning as described in any one of claims 1 to 8, characterized in that, Based on the target location and intent category entered by the user, the knowledge graph for satellite mission planning is used to query the correspondence between the target location and intent category, namely "target category matching" and "intent category matching". The target category and intent category found together locate the "payload usage rule" node in the rule base to obtain the payload category used by the task under the user intent. Based on the attributes of the "payload usage rule" node, the task attribute fields of the subordinate observation tasks of this user intent are filled, forming a formal observation task that is uploaded to the satellite for execution.

10. A user intent task decomposition method according to claim 9, characterized in that, The formal observation task is established as an "Observation Task" node in the requirement library, and an in-library entity relationship is established with the intent category node of the user intent, and a relationship is established with the target entity node in the target library.

Images