Spacecraft health management system and method, electronic equipment and storage medium

Abstract

The invention discloses a spacecraft health management system and method, electronic equipment and a storage medium, and relates to the technical field of spacecraft management, and the system comprises a knowledge base configuration module and a health diagnosis module; the knowledge base configuration module is used for configuring a diagnosis rule of telemetry data of the spacecraft through a visual interaction interface, the diagnosis rule is written by adopting a diagnosis script language, and the diagnosis script language supports data type declaration, condition expressions, control statements and built-in function calling; and the health diagnosis module is used for receiving telemetry data of the spacecraft in real time, performing logic judgment on the received telemetry data based on a configured diagnosis rule, and generating a parameter state change result and an anomaly detection result. According to the method, efficient logic judgment is carried out based on the configured diagnosis rule, an accurate parameter state change result and an anomaly detection result are generated, and the timeliness and reliability of anomaly recognition are remarkably improved.

Description

Technical Field

[0001] This invention relates to the field of spacecraft management technology, and in particular to a spacecraft health management system, method, electronic device, and storage medium. Background Technology

[0002] The telemetry data generated by spacecraft during their on-orbit operation is massive in scale and complex in type, posing a significant challenge to traditional health management systems in terms of real-time diagnosis and flexible response. Existing methods struggle to meet the accuracy and timeliness requirements for anomaly detection in multi-satellite, multi-mission scenarios, particularly in complex logical judgments and dynamic rule configuration. Furthermore, the strong correlation between telemetry parameters means that single-dimensional diagnosis can easily overlook system-level anomalies, leading to missed or false alarms, severely impacting the safety and reliability of spacecraft operations.

[0003] To address these issues, existing technologies typically employ diagnostic methods based on fixed thresholds or detection systems based on predefined rules. Some systems support configuring diagnostic logic via scripts, allowing users to write simple conditional statements or set parameter thresholds through a graphical interface. Other solutions introduce historical data comparison and pattern matching techniques, using statistical learning or expert systems to identify abnormal states. These systems achieve a degree of automated diagnosis, but their rule expression capabilities are limited, and they struggle to support multi-parameter joint diagnosis and dynamic context adaptation.

[0004] However, existing diagnostic systems still have many shortcomings: First, diagnostic rules lack flexibility and programmability, making it difficult to express complex logic and multi-parameter relationships; second, the system usually lacks the ability to update rules in real time, making it unable to adapt to the dynamic changes in on-orbit mission requirements; third, the diagnostic process is tightly coupled with the configuration interface, resulting in high user learning costs and cumbersome operation; fourth, the lack of a unified and scalable diagnostic language makes the system difficult to reuse and expand, limiting its application effectiveness in multi-satellite collaborative management and intelligent diagnosis.

[0005] In summary, existing spacecraft health management systems have significant shortcomings in terms of the flexibility, real-time performance, and configurability of diagnostic rules. There is an urgent need for a system architecture and method that can support complex logical expressions, possess visual interactive capabilities, and perform real-time multi-parameter joint diagnosis. This invention is proposed against this backdrop. Summary of the Invention

[0006] The technical problem to be solved by the present invention is to address the shortcomings of the prior art, and specifically provides a spacecraft health management system, method, electronic device and storage medium, as follows: 1) In a first aspect, the present invention provides a spacecraft health management system, the specific technical solution of which is as follows: Includes: a knowledge base configuration module and a health diagnosis module; The knowledge base configuration module is used to configure diagnostic rules for spacecraft telemetry data through a visual interactive interface. The diagnostic rules are written in a diagnostic scripting language, which supports data type declarations, conditional expressions, control statements, and built-in function calls. The health diagnosis module is used to: receive telemetry data from the spacecraft in real time, and perform logical judgments on the received telemetry data based on the configured diagnostic rules, generating parameter status change results and anomaly detection results.

[0007] The beneficial effects of the spacecraft health management system provided by this invention are as follows: By introducing a diagnostic scripting language and a visual interactive interface, the flexibility and programmability of diagnostic rules are effectively improved. The diagnostic scripting language supports data type declarations, conditional expressions, control statements, and built-in function calls, enabling users to express complex logic and multi-parameter relationships, overcoming the limited expressive capabilities of traditional system rules. The visual interactive interface of the knowledge base configuration module reduces user learning costs and operational complexity, enabling intuitive configuration and dynamic updates of diagnostic rules. The health diagnosis module receives telemetry data from the spacecraft in real time and performs efficient logical judgments based on the configured diagnostic rules, generating accurate parameter state change results and anomaly detection results, significantly improving the timeliness and reliability of anomaly identification. The system also supports multi-satellite collaborative management and extended applications through a unified diagnostic language architecture, enhancing the system's adaptability and reusability. Overall, this invention plays a significant role in improving the automation level, response speed, and diagnostic accuracy of spacecraft health management.

[0008] Based on the above solution, the spacecraft health management system of the present invention can be further improved as follows.

[0009] Furthermore, it also includes a diagnostic and treatment record query module, which is used to record and provide treatment methods for querying abnormal detection results, including operation and maintenance expert suggestions.

[0010] The beneficial effects of adopting the above-mentioned further solution are as follows: Current spacecraft health management systems lack system recording and query functions for handling methods after anomaly detection. Operational suggestions from maintenance experts are difficult to effectively save and reuse, leading to low efficiency in fault handling and reliance on personal experience. By recording and providing query functions for handling methods related to anomaly detection results through the diagnostic handling record query module, including operational suggestions from maintenance experts, complete traceability of the handling process and knowledge accumulation are achieved. This improves the standardization and response speed of fault handling, promotes the sharing and reuse of maintenance experience, and enhances the system's practicality and reliability.

[0011] Furthermore, it also includes a diagnostic history query module, which is used to query historical diagnostic information by spacecraft, time, and parameter code in multiple dimensions. The historical diagnostic information includes parameter name, parameter value, diagnostic information, and response operation record.

[0012] The beneficial effects of adopting the above-mentioned further solution are as follows: Traditional spacecraft health management systems lack effective organization and multi-dimensional query capabilities for historical diagnostic information, leading to difficulties in fault analysis and status tracing. By using the diagnostic history query module to query historical diagnostic information by spacecraft, time, and parameter code, including parameter names, parameter values, diagnostic information, and response operation records, complete tracing and comprehensive analysis of the diagnostic process are achieved. This improves the efficiency of analyzing system status changes, supports rapid location of anomaly causes, provides a data foundation for optimizing diagnostic rules and improving handling plans, and enhances the continuity of system operation and maintenance and decision support capabilities.

[0013] Furthermore, the parameter status change results include the status type identifier and status change time of the telemetry parameters, and the anomaly detection results include alarm level, alarm description information, solution suggestions, and recommended operation instructions.

[0014] The beneficial effects of adopting the above-mentioned further solutions are as follows: Traditional health management systems output fragmented diagnostic results, lacking a unified structure and complete context, which affects the efficiency of fault diagnosis and handling. By clearly defining the parameter status change results as including the status type identifier and status change time of telemetry parameters, and the anomaly detection results as including alarm level, alarm description information, solution suggestions, and recommended operation instructions, the diagnostic output information is structured and standardized. This helps maintenance personnel quickly understand the nature and urgency of the anomaly and directly obtain targeted operation guidance, improving the operability and handling efficiency of the diagnostic results and enhancing the system's comprehensive response capability to on-orbit anomalies.

[0015] 2) In a second aspect, the present invention also provides a spacecraft health management method, the specific technical solution of which is as follows: Diagnostic rules for spacecraft telemetry data can be configured through a visual interactive interface. These rules are written in a diagnostic scripting language that supports data type declarations, conditional expressions, control statements, and built-in function calls. It receives telemetry data from spacecraft in real time, performs logical judgments on the received telemetry data based on configured diagnostic rules, and generates parameter status change results and anomaly detection results.

[0016] Based on the above scheme, the spacecraft health management method of the present invention can be further improved as follows.

[0017] Furthermore, it also includes: recording and providing methods for handling query anomaly detection results, wherein the handling methods include operational suggestions from operations and maintenance experts.

[0018] Furthermore, it also includes: querying historical diagnostic information by spacecraft, time, and parameter code in multiple dimensions. The historical diagnostic information includes parameter name, parameter value, diagnostic information, and response operation records.

[0019] Furthermore, the parameter status change results include the status type identifier and status change time of the telemetry parameters, and the anomaly detection results include alarm level, alarm description information, solution suggestions, and recommended operation instructions.

[0020] 3) In a third aspect, the present invention also provides an electronic device, the electronic device including a processor coupled to a memory, the memory storing at least one computer program, the at least one computer program being loaded and executed by the processor, so as to enable the electronic device to implement any of the above-mentioned spacecraft health management methods.

[0021] 4) In a fourth aspect, the present invention also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements any of the above-described spacecraft health management methods.

[0022] It should be noted that the beneficial effects of the technical solutions of the second to fourth aspects of the present invention and their corresponding possible implementations can be found in the above description of the technical effects of the first aspect and its corresponding possible implementations, and will not be repeated here. Attached Figure Description

[0023] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments of the present invention will be briefly introduced below: Figure 1 This is a schematic diagram of the structure of a spacecraft health management system according to an embodiment of the present invention; Figure 2 This is a flowchart illustrating a spacecraft health management system according to an embodiment of the present invention. Detailed Implementation

[0024] The principles and features of the present invention are described below. The examples given are only for explaining the present invention and are not intended to limit the scope of the present invention.

[0025] The technical solution of the present invention and how the technical solution of the present invention solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of the present invention will now be described with reference to the accompanying drawings.

[0026] like Figure 1 As shown in the figure, a spacecraft health management system according to an embodiment of the present invention includes: a knowledge base configuration module and a health diagnosis module; The knowledge base configuration module is used to configure diagnostic rules for spacecraft telemetry data through a visual interactive interface. These diagnostic rules are written in a diagnostic scripting language, which supports data type declarations, conditional expressions, control statements, and built-in function calls. The specific implementation process is as follows: 1) Users access the knowledge base configuration module through a visual interactive interface. This interface provides graphical elements such as buttons, drop-down menus, text boxes, and a code editor for inputting and editing diagnostic rules. Users can select satellites and parameter codes, and choose or customize the diagnostic rule type, such as multi-level threshold rules or numerical range rules. 2) In the background, the graphical rule elements input by the user are converted into diagnostic scripting language code. For example, when a user sets a parameter threshold, the system automatically generates the corresponding conditional expression and built-in function call code. 3) The generated diagnostic script undergoes syntax and semantic validation to ensure that the code conforms to the specifications of the diagnostic scripting language, including checking whether the data type declaration is correct, whether the conditional expression is valid, whether the control statement structure is complete, and whether the built-in function call parameters are valid. 4) After successful validation, the system saves the diagnostic rule to the knowledge base database and associates it with the corresponding satellite and parameter information. 5) Users can preview, test, and modify diagnostic rules through the interface. The system provides real-time feedback, such as highlighting syntax errors or simulating execution results. The entire implementation process ensures the configurability, correctness, and maintainability of the diagnostic rules, supporting the judgment of telemetry anomalies with complex logic.

[0027] Spacecraft telemetry data refers to various parameter information transmitted from the spacecraft to the ground station via a telemetry system. This data includes the spacecraft's state parameters, environmental parameters, and engineering parameters, such as voltage, temperature, pressure, and attitude angles. Spacecraft telemetry data is typically transmitted in digital or analog signal form, and after demodulation and processing, it is stored and analyzed to monitor the spacecraft's real-time operational status and health condition. Spacecraft telemetry data forms the basis of the health diagnostic module; by analyzing this data, the system can detect anomalies and generate alarm information.

[0028] Diagnostic rules are a set of logical instructions written in a diagnostic scripting language, used to define how to analyze and determine whether anomalies exist in spacecraft telemetry data. Diagnostic rules are based on user-configured conditions and thresholds; for example, multi-level threshold rules specify different levels of threshold values ​​for parameter values, numerical range rules define the normal range of parameters, and correlation condition rules combine the relationships between multiple parameters for comprehensive judgment. Diagnostic rules are edited and stored through a visual interactive interface, allowing users to flexibly customize the detection logic and ensure the system can adapt to the needs of different spacecraft and missions.

[0029] Data type declaration is a syntactic structure in diagnostic scripting languages ​​used to define the data type and initial value of a variable. Supported data types include integer, long integer, floating-point, double-precision floating-point, string, and boolean. For example, in a script, a user can use the statement "float a=3.22" to declare a floating-point variable 'a' and assign it the initial value 3.22. Data type declaration ensures type consistency of variables in expressions and function calls, prevents runtime errors, and improves code readability and maintainability.

[0030] Conditional expressions are logical expressions used in diagnostic scripting languages ​​to compare values. They support operators such as equality, inequality, AND, and OR. For example, the conditional expression "a==1&&b==10" means that the value of variable a is 1 and the value of variable b is 10. Conditional expressions are typically used in control statements as conditions to determine whether to execute a specific block of code. They allow users to define complex logical conditions, enabling multi-parameter correlation analysis and anomaly detection.

[0031] Control statements, in diagnostic scripting languages, are used to control the execution flow of a program. These include the `if` statement, `ifelse` statement, and `while` statement. The `if` statement executes a block of statements while a condition is true; the `ifelse` statement executes a block of statements while a condition is true, and another block of statements otherwise. The `while` statement repeatedly executes a block of statements while a condition is true. For example, in a script, `while(n<5){n=n+1}` means that when the variable `n` is less than 5, the operation of incrementing `n` by 1 is repeated. Control statements enable diagnostic rules to handle loops and branching logic, adapting to dynamically changing telemetry data.

[0032] Built-in function calls are predefined functions in the diagnostic scripting language. Users can directly call these functions to perform specific operations, such as retrieving telemetry parameter values, outputting messages, or checking time. For example, the built-in function call "getVal("P30W12W13")" is used to retrieve the telemetry parameter value with parameter code P30W12W13, while "errormsg("Parameter abnormal; 3")" is used to output an error message and specify the alarm level. Built-in function calls simplify the writing of diagnostic rules, provide commonly used functional modules, and ensure concise and efficient code.

[0033] The health diagnosis module is used to: receive telemetry data from the spacecraft in real time, and perform logical judgments on the received telemetry data based on configured diagnostic rules, generating parameter status change results and anomaly detection results. The parameter status change results include the status type identifier and status change time of the telemetry parameters, while the anomaly detection results include alarm level, alarm description information, solution suggestions, and recommended operation instructions. The specific implementation process is as follows: 1) The health diagnostics module establishes a connection with the message queue and initializes the runtime environment. Upon startup, the module first loads the configuration file to determine the message queue topics to be listened to; these topics correspond to telemetry data streams from different satellites. The module creates multiple message consumer instances, each responsible for processing the data stream from a specific satellite, using thread pool technology for parallel processing. Simultaneously, the module loads diagnostic rules from a relational database. These rules are written in a diagnostic scripting language and stored in a knowledge base table. The loading process includes querying the diagnostic rules for currently active satellites, parsing the script syntax, compiling the script into intermediate code, and caching it in memory to improve execution efficiency. The module also initializes a time-series database connection to prepare for storing diagnostic results. In this step, the module performs a self-check, verifying the connection status of all external services to ensure that the message queue, database, and caching system are all accessible.

[0034] 2) The health diagnosis module receives and preprocesses real-time telemetry data. When new telemetry data arrives in the message queue, the module's message listener immediately captures this data. The raw telemetry data is in binary or JSON format, containing fields such as parameter codes, parameter values, and timestamps. The preprocessing stage first parses the data, extracting key fields and converting them into internal data objects. Next, data cleaning is performed, including removing obvious outliers such as data exceeding physical limits, handling missing values ​​through interpolation or using the last valid value, and smoothing noisy data using a moving average algorithm. The data standardization stage normalizes parameter values ​​of different dimensions to a unified range, facilitating subsequent rule matching. The module also records a precise reception timestamp for each parameter, with millisecond-level accuracy, providing a benchmark for state change times. The preprocessed data is organized into parameter sets, categorized by satellite and parameter code, and stored in an in-memory data structure.

[0035] 3) The health diagnosis module performs diagnostic rule matching and logical judgment. The module retrieves the diagnostic rule set corresponding to the current satellite from the cache and applies the relevant rules to each parameter. The rule matching process uses an interpreted execution mode. The module has a built-in interpreter for the diagnostic scripting language, capable of parsing and executing script code line by line. The execution environment provides a complete variable declaration space, conditional expression evaluation functions, and built-in function call support. For each parameter, the interpreter first obtains the current parameter value using the `getVal` function, and then executes conditional judgments according to the script sequence. When a status change is detected, the interpreter calls functions such as `message` and `errormsg` to generate output. The module handles the cumulative alarm logic specially, maintaining an alarm counter for each parameter and determining whether the alarm threshold has been reached based on a time window. During the rule matching process, the module records the execution trajectory in real time, including triggered conditional expressions, executed control statement branches, and function call sequences, providing a complete basis for result generation.

[0036] 4) Parameter state change results are generated by comparing the current diagnostic results with historical states. The module maintains a state machine for each parameter. When a change in the state type identifier is detected, the state machine is immediately updated and the state change time is recorded. The state type identifier is automatically determined based on multi-level thresholds defined in the diagnostic rules. For example, parameter values ​​within the range [0, 100] are identified as normal, (100, 200) as slightly abnormal, and values ​​greater than 200 as severely abnormal. Anomaly detection results are generated by collecting all output function calls from the diagnostic script. The module parses the parameters of the `errormsg` function to extract alarm level and alarm description information, obtains solution suggestions from the `solution` function, and obtains recommended operation instructions from the `operation` function. All this information is encapsulated into a unified result object containing complete metadata such as satellite number, parameter code, and generation timestamp. The module also performs logical verification on the results to ensure the integrity and consistency of each field.

[0037] 5) The generated result objects are first converted to a specific format, such as JSON or Protocol Buffers, and then storage and sending operations are performed in parallel. In the storage phase, parameter state change results and anomaly detection results are written to different tables in the time-series database, using an optimized batch insert strategy to improve write efficiency. The database tables are sharded by time, supporting fast historical queries. Simultaneously, the module sends key results to designated message topics through a message producer for downstream systems such as alarm services and visualization interfaces to consume. The module implements a robust transaction mechanism to ensure the atomicity of database writes and message sending. Finally, the module updates its internal state cache, including the latest parameter state type identifier and last update time, providing a baseline for the next diagnostic. Throughout the process, the module continuously monitors system resource usage and dynamically adjusts the processing rate to ensure stable operation under high load.

[0038] The status type identifier of telemetry parameters is one of the key pieces of information output by the health diagnosis module, used to accurately describe the health status classification of telemetry parameters at a specific time. This identifier is automatically generated based on multi-level thresholds and judgment logic defined in the diagnostic rules, with typical values ​​including discrete states such as normal, mildly abnormal, and severely abnormal. In the system implementation, the status type identifier is determined by the evaluation result of conditional expressions during the execution of the diagnostic script. When the parameter value meets different threshold conditions, the status type identifier is updated accordingly. The status type identifier directly corresponds to the visual coding in the user interface, with different states displayed using different colors to help users quickly identify the parameter's health status. The system establishes strict definition standards for each status type identifier to ensure consistency and objectivity in judgment.

[0039] The state change time is a precise timestamp recorded by the health diagnosis module, marking the moment when the telemetry parameter state type identifier changes. This timestamp is generated using a high-precision clock source, and its format follows international standard time representation, including year, month, day, hour, minute, second, and millisecond portions. Recording the state change time is crucial for analyzing parameter behavior patterns, enabling the system to track state transition sequences, calculate state durations, and establish causal relationships between changes in multiple parameter states. At the implementation level, the state change time is collected immediately when a state transition is detected by the diagnostic rules, ensuring the real-time nature and accuracy of the time recording. The system uses a time-series database to store the state change times, supporting complex query analysis based on time ranges.

[0040] Alarm level is a crucial indicator in anomaly detection results, quantifying the severity of the anomaly. Alarm levels employ a tiered system, typically represented by positive integers, with higher values ​​indicating more severe anomalies. For example, the system defines alarm level 1 as a minor anomaly, level 2 as a moderate anomaly, and level 3 as a severe anomaly. The alarm level is determined based on the threshold range set in the diagnostic rules and historical anomaly patterns, specified through the `errormsg` function parameter in the diagnostic script. In the system processing flow, the alarm level affects the priority of anomaly handling; higher-level alarms trigger more urgent response procedures. The alarm level is also associated with the notification policy, determining the channels and frequency of sending alerts to users.

[0041] The alarm description is the text component of the anomaly detection results, detailing the specific manifestations and characteristics of the anomaly. The alarm description uses a structured text format and includes key elements such as anomaly parameter information, anomaly values, and violated rules. This information is dynamically generated through output functions in the diagnostic script, combining runtime parameter states to construct the description. The alarm description is designed to be accurate and clear, including necessary technical details while ensuring ease of understanding for users. The system supports multilingual alarm descriptions, providing localized content based on different user preferences. The alarm description is prominently displayed in the user interface, serving as the primary reference for anomaly analysis.

[0042] The solution recommendations are guiding content within the anomaly detection results, providing specific methods and steps for resolving the detected anomalies. These recommendations are predefined based on domain expert knowledge and historical processing experience, and are output through the `solution` function in the diagnostic script. These recommendations include operational details such as technical inspection steps, parameter adjustment schemes, and system restart procedures, providing personalized solutions for different types of anomalies. The generation of solution recommendations considers practical feasibility, combining satellite operational status and ground support conditions to recommend the most suitable handling method. The system continuously optimizes the solution recommendation library, constantly updating and improving the recommendations based on feedback on processing effectiveness.

[0043] Recommended operation instructions are executable action suggestions from the anomaly detection results, guiding users or automated systems to execute specific control commands. These instructions use a standardized command format and include complete information such as the operation object, operation type, and parameter values. They are generated through the `operation` function in the diagnostic script, dynamically recommending the most effective operation based on the anomaly type and system status. Recommended operation instructions cover various operation types, including emergency measures such as parameter reset, mode switching, and function disabling. The system performs safety verification on the recommended operation instructions to ensure they comply with safety constraints and will not cause secondary failures. Recommended operation instructions are transmitted to the execution system through a dedicated interface, supporting both one-click execution and manual confirmation modes.

[0044] In another possible implementation, logical judgments are made on the received telemetry data based on configured diagnostic rules to generate parameter state change results and anomaly detection results, including: 1) Construct a dynamic diagnostic graph model to transform diagnostic rules into a graph structure representation, where nodes represent telemetry parameter states and edges represent logical relationships between parameters. Graph theory algorithms are used to establish the propagation paths and influence ranges of parameter states, enabling visualized modeling and topological analysis of diagnostic rules. Specifically: ① Parse diagnostic rules and extract graph model elements. The system reads the diagnostic rule scripts stored in the knowledge base configuration module and parses the diagnostic script language code line by line using a syntax analyzer. The parsing process identifies key elements in the diagnostic rules, including telemetry parameter codes, conditional expressions, control statements, and built-in function calls. For each telemetry parameter, the system creates a corresponding graph node, whose attributes include parameter code, parameter name, parameter type, and current parameter status. For logical relationships in the diagnostic rules, the system creates directed edges, whose attributes include association type, conditional expression, and influence weight. The system establishes a mapping table between nodes and edges, recording the set of incoming and outgoing edges for each node, providing basic data for subsequent graph traversal algorithms.

[0045] ② Construct the graph structure and calculate association weights. Based on the node and edge information obtained from the analysis, the system constructs a directed graph model G=(V,E), where V represents the set of nodes and E represents the set of edges. The association weights between nodes are calculated through a multi-factor comprehensive calculation, using the following formula: in, This represents the edge weight from node i to node j. This represents the relation strength calculated using the conditional expression complexity based on diagnostic rules. This represents the coupling coefficient based on the physical correlation between parameters. This indicates the frequency of associations based on historical diagnostic data. , , The weighting coefficients are satisfied. The system uses an adjacency list to store the graph structure, supporting efficient graph traversal operations.

[0046] ③ Implement graph theory algorithms to analyze state propagation paths. The system applies various graph theory algorithms to analyze the constructed graph model. Depth-first search is used to identify all possible paths for parameter state propagation, and breadth-first search is used to calculate the shortest path of influence for parameter state changes. The system implements optimal propagation path finding based on Dijkstra's algorithm, calculating the minimum cost path for state propagation between nodes. For key parameter identification, the system uses centrality analysis algorithms, including degree centrality, proximity centrality, and betweenness centrality calculations, to identify the most important nodes in the graph. The system also applies community detection algorithms to divide the graph into multiple parameter communities, where parameters within each community have close logical relationships.

[0047] ④ Develop visualization modeling and topology analysis functions. The system develops a graph model visualization component based on WebGL technology to achieve interactive display of the graph structure. In the visualization interface, nodes use different shapes and colors to distinguish parameter types, and edges use different thicknesses and colors to represent the strength and type of association. Users can adjust the graph layout by dragging and drop, and view different levels of graph details by zooming. The system provides a set of topology analysis tools, including path query, influence range analysis, and critical path identification functions. When a user selects a parameter node, the system automatically highlights its directly and indirectly related parameter nodes and generates a parameter state propagation path report. The system also supports the export and import of graph models, making it convenient for users to save and share analysis results.

[0048] Parameter status is a representation of the health status of telemetry parameters at a specific moment, derived through analysis and judgment of telemetry parameter values ​​using diagnostic rules. Parameter status includes a status type identifier and status metadata. The status type identifier includes discrete status values ​​such as normal, slightly abnormal, and severely abnormal. The status metadata includes statistical information such as the start time, duration, and number of changes. Changes in parameter status follow a state machine model; transitioning from one state to another requires satisfying specific conditional expressions. In the dynamic diagnostic graph model, parameter status, as a core attribute of graph nodes, propagates and influences parameters through edge relationships. Accurate judgment and effective management of parameter status are fundamental to the reliable diagnosis of the spacecraft health management system. Historical records of parameter status are stored in a time-series database, supporting status trend analysis and anomaly pattern recognition.

[0049] 2) Perform real-time correlation impact analysis. Based on the dynamic diagnostic graph, conduct multi-parameter collaborative diagnosis. When the state of a certain telemetry parameter changes, the graph traversal algorithm automatically identifies the set of affected related parameters, calculates the propagation probability and impact degree of the state change, and generates a parameter correlation impact report. Specifically: ① Monitor telemetry parameter status changes and trigger correlation analysis. The system monitors the status type identifiers of all telemetry parameters in real time. When a change in the status type identifier of a parameter is detected, the correlation impact analysis process is immediately triggered. The system records detailed information about the status change, including the parameter code, the status type identifier before the change, the status type identifier after the change, the timestamp of the status change, and the reason for the change. This information serves as input data for the correlation analysis. The system locates the corresponding node in the dynamic diagnostic graph based on the changed parameter code and marks that node as the propagation source. The system also records the system environmental parameters at the time of the status change, including the current time, satellite operating mode, and mission stage. These environmental parameters are used for subsequent impact degree calculations. The triggering mechanism adopts an event-driven model to ensure that status changes can be captured and processed in a timely manner.

[0050] ② The system uses a graph traversal algorithm to identify the set of associated parameters. Starting from the propagation source, the system traverses the dynamic diagnostic graph using an improved breadth-first search algorithm. During the traversal, the system explores all possible propagation paths along the directed edges, recording the nodes and edges visited. The algorithm sets a maximum propagation depth D to limit the traversal range and avoid infinite loops. For each visited node, the system calculates its topological distance to the propagation source, defined as the number of edges on the shortest path. The system maintains a set of associated parameters S, containing all potentially affected parameter nodes discovered through traversal. During the traversal, the system simultaneously records the reachable path information for each node, including path length, intermediate nodes visited, and path weight. After the traversal is complete, the system deduplicates and sorts the set of associated parameters S, arranging them in ascending order of topological distance.

[0051] ③ Calculate the propagation probability and impact of state changes. Based on graph structure attributes and historical data analysis, the system calculates the propagation probability of a state change from the source point to each associated parameter. The formula for calculating the propagation probability is: in, Let represent the propagation probability from node i to node j. This represents the weight of the k-th edge on the path. This represents the topological distance from node i to node j. This represents the correction factor based on historical data. The calculation of the degree of impact considers multiple dimensions, including parameter importance level, magnitude of state change, and system operation stage. The formula for calculating the degree of impact is: in, This indicates the degree of influence on node j. The importance coefficient of the propagation source is represented by the coefficient. This represents the sensitivity coefficient of node j. These represent environmental adjustment factors. The system calculates these two indicators for each associated parameter and ranks them according to their degree of influence.

[0052] ④ Generate and distribute parameter correlation impact reports. The system generates a structured parameter correlation impact report based on the calculation results. The report contains four main parts: The summary section provides an overall impact assessment, including the number of affected parameters, the highest impact level, and key propagation paths. The detailed analysis section lists detailed information for each correlated parameter, including parameter code, parameter name, current parameter status, propagation probability, impact level, and possible state change predictions. The propagation path analysis section displays the main propagation paths from the propagation source to each correlated parameter, including the sequence of nodes along the path and path weights. The response recommendation section provides targeted monitoring and response recommendations based on the impact analysis results. The report uses a unified template format, supporting both machine parsing and human reading. The system distributes the report to relevant subsystems, including the health diagnosis module, alarm system, and visualization interface, ensuring that the analysis results can be utilized in a timely manner.

[0053] 3) Implement an adaptive diagnostic learning mechanism. By continuously monitoring the correspondence between telemetry parameter state changes and diagnostic results, dynamically adjust the judgment threshold and logical association weights of diagnostic rules, and use historical diagnostic data to train a state prediction model to improve diagnostic accuracy and adaptability. Specifically: ① A complete data acquisition pipeline is constructed to continuously record the correspondence between telemetry parameter status changes and diagnostic results. The acquired data includes raw telemetry parameter values, parameter status type identifier change sequences, diagnostic rule execution results, diagnostic information output records, and actual anomaly confirmation information. The feature extraction module extracts key features from this data, including parameter value statistical features, status duration features, state transition frequency features, and diagnostic rule triggering features. The system uses a time-series database to store these feature data and establishes a feature index for rapid retrieval. A data quality control mechanism ensures the integrity and accuracy of the acquired data, automatically identifying and removing abnormal data points. Feature data is organized according to time windows, supporting analysis and modeling at different time granularities.

[0054] ② Based on the collected feature data, the system periodically analyzes the execution effect of diagnostic rules. For threshold adjustment, the system uses a sliding window statistical method to calculate the distribution characteristics of parameter values ​​and dynamically optimizes the threshold setting based on actual diagnostic results. The threshold adjustment formula is: in, This indicates the adjusted threshold. Indicates the current threshold. The optimal threshold is calculated based on historical data. Here, represents the learning rate parameter. For adjusting the logical correlation weights, the system uses gradient descent to optimize the weight configuration, with the objective function being to minimize the diagnostic error. The weight update formula is: ,in, This indicates the updated weights. Indicates the current weight. Indicates the learning rate. This represents the gradient of the weights with respect to the diagnostic error. The system establishes a version management mechanism to record the historical trajectory of all parameter adjustments.

[0055] ③ A training dataset is constructed using historical diagnostic data. This dataset contains input features and corresponding label information. Input features include current telemetry parameters, historical state sequences, environmental parameters, and task stage information. Label information includes subsequent state changes and diagnostic results. Supervised learning is used for model training, employing a neural network algorithm to build a state prediction model. The network structure includes an input layer, multiple hidden layers, and an output layer. The hidden layers use the ReLU activation function, and the output layer uses the Softmax function to generate the state probability distribution. Backpropagation is used to optimize network parameters during training, and cross-entropy loss is used as the loss function. Model evaluation uses a reserved test dataset to calculate metrics such as accuracy, recall, and F1 score. The system is periodically retrained to ensure the model can adapt to the latest operating conditions.

[0056] ④ The trained state prediction model is integrated into the diagnostic system through a standardized interface. A blue-green deployment strategy is used to ensure service continuity. The online inference service receives real-time telemetry data and outputs state prediction results and confidence scores. The performance evaluation module continuously monitors the model's predictive performance and compares the degree of agreement between the prediction results and the actual state. Evaluation metrics include prediction accuracy, early warning timeliness, and false alarm rate. The system establishes a feedback collection mechanism to record confirmation and correction information from operations and maintenance personnel regarding the prediction results. Based on the evaluation results, the system automatically triggers model retraining or parameter adjustment processes. Performance evaluation reports are generated periodically, including model performance trend analysis and improvement suggestions, providing a basis for subsequent optimization.

[0057] 4) Perform multi-level verification and decision fusion. The credibility of the preliminary diagnostic results is assessed using evidence theory, and decision-level fusion is performed by combining multi-source diagnostic information. Multi-level verification thresholds are set to ensure the reliability of the diagnostic results. Finally, verified parameter state change results and anomaly detection results are generated. The specific implementation process is as follows: ① Collect multi-source diagnostic information and construct an evidence set. The system acquires diagnostic information from multiple output channels of the health diagnosis module, including direct diagnostic results based on diagnostic rules, correlation analysis results based on dynamic diagnostic graph models, prediction results based on state prediction models, and matching results of historical similar cases. The information output from each diagnostic channel is converted into a standardized evidence format, which includes metadata such as diagnostic conclusions, confidence scores, evidence source identifiers, and timestamps. The system establishes an evidence quality assessment mechanism, scoring each piece of evidence based on the historical accuracy of its source, the freshness of its creation, and the logical consistency between pieces of evidence. The evidence set is organized according to diagnostic target parameters and diagnostic time windows, forming a complete multi-source diagnostic information matrix. Rows in the matrix correspond to different diagnostic channels, columns correspond to different diagnostic time points, and cells store specific evidence data. This organizational structure provides standardized input data for subsequent evidence fusion, ensuring data consistency and comparability.

[0058] ② Applying evidence theory for credibility assessment. The system uses Dempster-Shafer evidence theory to handle uncertainties in the diagnostic process and constructs an identification framework. It includes all possible diagnostic conclusions. For each piece of evidence, the system establishes a basic probability assignment function. ,satisfy and Evidence fusion employs Dempster's combination rule for two independent pieces of evidence. and The basic probability distribution after combination is calculated as follows: in, This represents a subset of target hypotheses within the identification framework. and Represents any subset of hypotheses in the recognition framework. Indicates the factor of evidence conflict and The system recursively applies combination rules to progressively integrate all evidence, ultimately obtaining a comprehensive credibility assessment result. The credibility assessment output includes a trust function. and likelihood function This provides a confidence interval estimate for each diagnostic conclusion. The confidence function represents the confidence interval for the hypothesis. The minimum confidence level, the likelihood function represents the probability of the hypothesis. The highest possible credibility.

[0059] ③ Set multi-level verification thresholds and perform result filtering. The system establishes three levels of verification standards, with specific verification thresholds set for each level. The first level of verification focuses on the internal consistency of diagnostic results, checking for logical conflicts between different diagnostic conclusions for the same parameter. The system calculates a conflict index. The formula is ,in This represents the basic probability allocation for each diagnostic conclusion. A consistency threshold is set. ,when A re-diagnosis is triggered at this time. The second level of validation focuses on the consistency between the diagnostic results and historical patterns. A pattern consistency score is calculated by matching the results with patterns from historical normal and abnormal states. Set compliance threshold. ,when Manual confirmation is required at this stage. The third level of verification focuses on the contextual rationality of the diagnostic results, assessing the contextual rationality score of the diagnostic conclusions in conjunction with the satellite's operational phase, mission status, and environmental parameters. Set a reasonable threshold. ,when The auxiliary diagnostic process is initiated at the appropriate time. The system adopts a serial verification method, and the diagnostic result must pass through all verification levels in sequence. The result that fails verification at any level will be marked as pending confirmation.

[0060] ④ Based on the validated diagnostic information, a weighted decision fusion algorithm is used to generate the final diagnostic conclusion. The fusion process considers the weights of different diagnostic channels, and the weight allocation is based on the historical accuracy and real-time performance indicators of each channel. The decision fusion function is: in This represents the fused decision value. Indicates the first The weight of each diagnostic channel and satisfying , Indicates the first Decision output of each diagnostic channel and , This indicates the total number of diagnostic channels. The system sets decision thresholds. ,when The system accepts diagnostic conclusions promptly; otherwise, it rejects them or requires manual confirmation. For parameter status changes, the system records the status type identifier and the time of the status change, and attaches a confidence level label. For anomaly detection results, the system determines the alarm level, improves the alarm description information, optimizes solution suggestions, and refines recommended operation instructions. All final diagnostic results come with complete confidence assessment and verification records to ensure the traceability and reliability of the diagnostic results. The system also records key indicators during the fusion process to the diagnostic history database to support subsequent auditing and analysis.

[0061] Optionally, the above technical solution also includes a diagnostic treatment record query module. This module is used to record and provide treatment methods for querying abnormal detection results, including operational suggestions from maintenance experts. The specific implementation process is as follows: 1) The diagnostic treatment record query module performs system initialization and data source configuration. Upon module startup, it first loads the configuration file, which is in YAML format and includes message queue connection parameters, database connection pool settings, cache configuration, and business rule definitions. The module initializes message queue consumer groups, subscribing to health diagnostic topics partitioned by satellite number to ensure that anomaly detection results from the same satellite are processed sequentially. Simultaneously, the module establishes a connection pool with the main database, setting the minimum number of connections to 5, the maximum number to 50, and the connection timeout to 30 seconds. The module also initializes an Elasticsearch client for full-text search of treatment records. At the caching level, the module configures a Redis cluster connection and defines treatment template caching, expert information caching, and hot query result caching. After startup, the module sends a ready signal to the service registry and begins receiving processing requests.

[0062] 2) The diagnosis and treatment record query module receives and parses anomaly detection results. The module receives anomaly detection result messages in real time through a message queue listener. The message format uses Protocol Buffers for serialization and includes the fields: message_id, satellite_id, parameter_code, alert_level, alert_description, detection_time, solution_suggestions, and recommended_operations. Received messages first undergo a message verification process, with verification rules including field integrity checks, data format validation, and business logic verification. For messages that fail verification, the module transfers them to a dead-letter queue for further analysis. Verified messages are converted into an internal data model, with data enrichment performed during the conversion process. For example, detailed parameter information can be queried based on parameter_code, and satellite configuration information can be obtained based on satellite_id. The converted data object is assigned a unique treatment record ID, generated using the snowflake algorithm to ensure uniqueness in a distributed environment.

[0063] 3) The diagnostic treatment record query module automatically matches and generates treatment methods. The module uses a rule engine to analyze the received anomaly detection results. The rule engine, based on the Drools framework, contains over 200 treatment rules. Rules are organized by anomaly type and urgency. The rule matching process uses the Rete algorithm, with a matching efficiency of O(1) time complexity. For each anomaly detection result, the rule engine outputs one or more treatment plans, including treatment steps, expected effects, risk warnings, and required resources. The module also queries the treatment template library, which is organized into five levels: "Satellite Type - Subsystem - Equipment - Parameter - Anomaly Type," supporting fuzzy matching and similarity matching. The matching degree calculation formula is: in, Indicates the total matching degree. Indicates type matching degree. Indicates the parameter matching degree. Indicates historical matching degree, , , This represents the weighting coefficient. Templates with a matching degree exceeding the threshold of 0.8 are automatically adopted, and basic processing methods are generated.

[0064] 4) The diagnostic and treatment record query module integrates operation suggestions from maintenance experts. The module provides multiple channels for expert intervention, including a web portal, mobile app, and API interface. Expert authentication employs a two-factor authentication method to ensure system security. After logging in, the system assigns appropriate treatment tasks to experts using a recommendation algorithm that considers their professional field, workload, and historical treatment results. The input interface for expert operation suggestions provides rich editing tools, supporting a mix of structured forms and free text input. Key fields include: detailed explanation of operation steps, suggested timing of operation, range of operation parameters, safety precautions, effect verification methods, and rollback plans. The module performs real-time grammar checks and logical validation on the expert input to ensure the accuracy and operability of the suggestions. After an expert submits a suggestion, the system automatically manages the version, recording the suggestion's creation time, modification history, and review status.

[0065] 5) The diagnosis and treatment record query module stores and indexes treatment records. The module employs a multi-level storage architecture, with recent records stored in a MySQL relational database and historical records periodically archived to a time-series database. The MySQL tables use a normalized structure, with main tables including: a main treatment record table, an anomaly information extension table, a treatment method details table, an expert advice table, and a feedback record table. Indexing strategies include creating B+ tree indexes on frequently used query fields, composite indexes on compound query fields, and inverted indexes on full-text search fields. The module also synchronizes treatment records to an Elasticsearch cluster, establishing a full-text search index that supports fuzzy queries, synonym queries, and relevance sorting. To improve query performance, the module uses Redis to cache hot data, with the cache key designed in the "satellite number: anomaly type: time range" pattern, and the cache invalidation strategy using the LRU algorithm.

[0066] 6) The Diagnostic Treatment Record Query Module provides advanced query and visualization functions. The query interface supports RESTful specifications and offers rich query parameters, including pagination parameters, sorting parameters, filtering conditions, and aggregation requirements. A complex query example: query all treatment records for alarms of level 3 or above for a specific satellite within the past month, sorted by treatment effectiveness, and statistically analyzing the frequency of various anomalies. The query engine is implemented based on QueryDSL and supports dynamic combinations of query conditions. Query results are returned in paginated form, with 20 records per page by default and a maximum of 100 records supported. The front-end interface provides various visualization components, including a timeline view displaying the treatment process, a topology map showing related anomalies, and statistical charts analyzing treatment effectiveness. The module also provides export functionality, supporting exporting query results to Excel, PDF, and other formats to meet offline analysis needs.

[0067] 7) After each action is completed, a feedback collection request is automatically sent to the relevant operations and maintenance personnel. The feedback form includes fields such as action effectiveness score, action process evaluation, and improvement suggestions. After cleaning and standardization, the feedback data enters the knowledge optimization pipeline. The optimization algorithm analyzes the correlation between action records and feedback data to calculate the effectiveness indicators of the action methods. For action methods with significant effects, the system automatically increases their priority; for methods with poor effects, the system triggers a revision process. The effectiveness of expert recommendations is evaluated using statistical analysis methods, with evaluation indicators including adoption rate, success rate, and user satisfaction. The system regularly generates knowledge optimization reports to guide the continuous improvement of action rules and templates. All optimization processes are logged in detail, supporting auditing and traceability.

[0068] The handling methods for abnormal detection results refer to a series of technical measures and management processes established for abnormal information output by the health diagnosis module. These methods are designed based on the characteristic attributes of the abnormality, including abnormality type, severity level, scope of impact, and urgency. Each method includes specific operational instructions, inspection procedures, parameter adjustment ranges, and verification standards, forming a complete handling plan. Within the system, handling methods are sourced from multiple channels, including pre-set standardized handling procedures, summaries and refinements of historical successful cases, and transfer of experience from handling similar abnormalities. The handling methods are organized according to a logical framework of "identification-analysis-decision-execution-verification" to ensure the scientific and standardized nature of the handling process. Each handling method is associated with effectiveness evaluation indicators, which are used to continuously optimize the quality and applicability of the handling methods.

[0069] Operational suggestions from operations and maintenance (O&M) experts refer to professional guidance and technical advice provided by domain experts with extensive practical experience. These suggestions are based on the experts' in-depth understanding of specific anomaly scenarios, combined with the system's operating environment and task requirements, providing targeted solutions. O&M expert operational suggestions include detailed technical operation guidelines, parameter adjustment suggestions, risk control measures, and anomaly recovery plans. The process of generating these suggestions integrates the experts' theoretical knowledge and practical experience, often including innovative ideas and special techniques beyond standard procedures. Within the system, O&M expert operational suggestions undergo structured organization and standardization, establishing a correlation with corresponding anomaly types and handling methods. After these suggestions are validated through practical application, some best practices are incorporated into the standard handling method library, achieving continuous accumulation and inheritance of organizational knowledge.

[0070] In another possible implementation, the process of obtaining and processing anomaly detection results includes: 1) Construct an anomaly handling knowledge graph, linking historical anomaly detection results with corresponding handling methods to form a multi-dimensional knowledge network containing anomaly types, parameter features, handling plans, and effect evaluations. This knowledge graph is stored using a graph structure, where nodes represent anomaly entities and handling method entities, and edges represent semantic relationships and causal connections between entities. The specific implementation process is as follows: ① Extract historical anomaly detection results and treatment method data from multiple data sources. The system connects to the diagnostic history database, the diagnostic treatment record database, and the health management public service database to query all historical anomaly detection result records and corresponding treatment method records. The data extraction process includes three main parts: anomaly detection result data extraction to obtain parameter names, parameter codes, parameter values, diagnostic information, alarm levels, and anomaly occurrence times; treatment method data extraction to obtain treatment plan descriptions, operation steps, solution suggestions, and recommended operation instructions; and effect evaluation data extraction to obtain treatment execution results, treatment effect scores, and subsequent verification information. The system performs data cleaning on the extracted raw data, including removing duplicate records, completing missing fields, standardizing terminology, and standardizing data formats. After data cleaning, the system establishes a temporary data warehouse, linking and aligning data from different sources according to time series and parameter codes.

[0071] ② Identify and define entities and relationships in the knowledge graph. The system uses natural language processing (NLP) technology to analyze text data and identify key entities. Anomaly entities include anomaly type entities, parameter feature entities, and environmental context entities; handling method entities include operation step entities, solution entities, and resource requirement entities. Entity identification employs a combination of rule-based and machine learning methods. The rule-based approach uses a predefined domain dictionary and pattern matching, while the machine learning approach uses a named entity recognition model. The relationship definition process establishes various association types between entities. Semantic relationships include synonym relationships, hierarchical relationships, and component relationships; causal relationships include trigger relationships, dependency relationships, and influence relationships. The system assigns a unique identifier to each entity and defines an attribute set for each relationship, forming the metadata model of the knowledge graph.

[0072] ③ Construct the graph structure and calculate relation weights. Based on the identified entities and relations, the system constructs a directed weighted graph. .in This represents a set of nodes, containing all exception entities and handling method entities. This represents the set of edges, containing all semantic relationships and causal connections. This represents the set of edge weights. Weight calculation is based on statistical analysis of historical data and domain knowledge; the formula is as follows: in Indicates from node To the node edge weights, This represents a statistic based on co-occurrence frequency. This represents the confidence level based on domain knowledge. Indicates the strength of time-related correlation. , , These are the weighting coefficients. The system uses a graph database to store the knowledge graph, employing a combination of adjacency lists and attribute tables to support efficient graph traversal and relationship queries.

[0073] ④ Achieve Knowledge Fusion and Quality Assessment. The system performs multi-source knowledge fusion on the constructed knowledge graph to resolve conflicts and inconsistencies between different data sources. Knowledge fusion includes three sub-processes: entity alignment, relation disambiguation, and attribute fusion. Entity alignment is based on similarity calculation, identifying and merging different nodes pointing to the same entity. Relationship disambiguation is based on context analysis to determine the specific semantic meaning of relations. Attribute fusion is based on credibility assessment, selecting the most reliable attribute values. The quality assessment stage checks the completeness, accuracy, and consistency of the knowledge graph. Completeness assessment checks the coverage of key entities and relations; accuracy assessment verifies the correctness of knowledge through sampling; and consistency assessment checks for logical conflicts and contradictory relationships. Based on the assessment results, the system optimizes and corrects the knowledge graph to ensure that its quality meets application requirements.

[0074] ⑤ Develop a knowledge graph update and maintenance mechanism. The system establishes a continuous knowledge graph update process, periodically obtaining new anomaly detection results and handling methods from data sources, and automatically performing entity recognition, relationship extraction, and graph structure updates. The update process adopts incremental processing, only processing the changed data parts to improve update efficiency. The system implements version management functions, recording the historical versions and change records of the knowledge graph, and supporting version rollback and change traceability. The maintenance mechanism includes anomaly detection, performance optimization, and storage management. Anomaly detection monitors the logical consistency of the knowledge graph, performance optimization improves query efficiency through index optimization and caching strategies, and storage management is responsible for data backup and recovery. The system also provides a visual display of the knowledge graph, supporting interactive exploration and analysis.

[0075] 2) Perform multi-dimensional feature analysis on the current anomaly detection results, extracting anomaly type identifiers, alarm levels, parameter code sets, time features, and contextual information. Represent this information using feature vectors, and map these feature vectors to the semantic space of the knowledge graph through an embedding model. The specific implementation process is as follows: ① Extract structured feature data from anomaly detection results. Receive anomaly detection results output by the health diagnosis module. These results include fields such as alarm level, alarm description information, solution suggestions, and recommended operation instructions. The feature extraction process first parses the anomaly type identifier, classifying it into predefined anomaly types based on keywords and semantic patterns in the diagnostic information. The alarm level is directly taken from the numerical field of the anomaly detection result, and the parameter code set is obtained by analyzing parameter references in the alarm description information and solution suggestions. Temporal features include time-series information such as anomaly occurrence time, duration, and frequency, extracted from diagnostic history records. Contextual environment information includes environmental parameters such as satellite operation mode, mission stage, and equipment status, obtained by querying the satellite configuration module and real-time telemetry data.

[0076] ② The extracted features are converted into numerical feature vectors. Specifically, various numerical methods are used to process different types of feature data. Anomaly type identifiers are converted into sparse vectors using one-hot encoding, and alarm levels are directly used as numerical features. The parameter code set is represented by TF-IDF vectorization, and the calculation formula is as follows: in, Indicates the parameter code. This indicates the current anomaly detection result. This indicates the frequency of the parameter code in the exception description. This indicates the total number of abnormal detection results. This indicates the number of anomaly detection results containing this parameter code. Time features are converted into multiple numerical dimensions, including periodic features such as hours, days of the week, and months. Contextual information is processed according to type; categorical variables use one-hot encoding, and continuous variables are normalized. All numerical features are finally concatenated into a unified feature vector. ,in This represents the total dimension of the feature vector.

[0077] ③ The system uses an embedding model to map feature vectors to the semantic space. The system employs a neural network-based embedding model, whose structure includes an input layer, multiple hidden layers, and an output layer. The input layer receives the feature vectors. The hidden layer uses the ReLU activation function for non-linear transformation, and the output layer generates a low-dimensional semantic vector. ,in This represents the dimension of the semantic space. The mapping process is represented as: in, , Represents the weight matrix. , This represents the bias vector. The model is trained using a contrastive learning approach. The objective function aims to make the semantic vectors of similar anomalies close in semantic space, while keeping the semantic vectors of dissimilar anomalies far apart. Training data comes from historical anomaly detection results and their semantic relationships in the knowledge graph. The model is periodically fine-tuned using new anomaly data to maintain the accuracy of semantic mapping.

[0078] ④ Align the mapped semantic vectors with the semantic space of the knowledge graph. The alignment process is based on anchor entities, which are defined in both the feature vector space and the knowledge graph semantic space. The alignment function is expressed as: ,in, This represents the aligned semantic vector. Represents a linear transformation matrix. Let represent the translation vector. The optimization process minimizes the alignment error, and the objective function is: in, Indicates the first Aligned semantic vectors of anomaly detection results Represents the semantic vector of the corresponding entity in the knowledge graph. This indicates the number of anchor entities. The system uses the gradient descent algorithm to optimize the transformation parameters, ensuring consistency between the feature vector space and the semantic space of the knowledge graph.

[0079] ⑤ Verify semantic mapping quality and handle anomalies. The system establishes a semantic mapping quality assessment mechanism, with assessment metrics including mapping accuracy, recall, and semantic consistency. Mapping accuracy assesses the degree of matching between semantic vectors and real semantics in the knowledge graph; recall assesses the proportion of effective mappings; and semantic consistency assesses the reasonableness of the distribution of mapping results in the semantic space. For anomaly detection results with poor mapping quality, the system initiates anomaly handling procedures, including feature re-extraction, model re-mapping, and manual review. The system also implements a semantic vector caching mechanism to cache the semantic vectors of frequently occurring anomaly patterns, improving mapping efficiency. All mapping processes and results are recorded in the log system to support subsequent analysis and optimization.

[0080] 3) Perform similarity search and path reasoning in the anomaly handling knowledge graph. Search for historical similar anomaly cases based on the cosine similarity of feature vectors. Simultaneously, discover potential propagation paths for handling methods through graph traversal algorithms, and calculate the matching degree and confidence score of candidate handling methods. The specific implementation process is as follows: ①The semantic vector of the current anomaly detection result Similarity is calculated between the semantic vectors of the data and the semantic vectors of all historical anomaly cases in the knowledge graph. The cosine similarity method is used for the calculation, and the formula is as follows: in, Represents the first in a knowledge graph Semantic vectors of historical anomaly cases, Representing vectors The modulus length. The system sets a similarity threshold. Filter out all that meet the requirements Historical anomaly cases are analyzed. The similarity search process employs an approximate nearest neighbor algorithm, significantly improving search efficiency by constructing an index structure for semantic vectors. The searched similar anomaly cases are sorted from high to low according to their similarity scores, forming an initial candidate case set.

[0081] ② The system employs a graph traversal algorithm to discover the propagation path of the handling method. Starting from the entity node corresponding to the current anomaly detection result, the system performs a multi-level graph traversal within the anomaly handling knowledge graph. The traversal process uses an improved breadth-first search algorithm with a set maximum search depth. During the traversal, the system records all paths from the exception node to the handling method node and calculates the propagation strength of each path. The formula for calculating the propagation strength is: in, Indicates a transmission path, Represents the edges in the path. Representing an edge The weight, Indicates path length. The system filters propagation strength exceeding a threshold. The paths represent potential disposal methods and propagation relationships. Graph traversal considers both node type and relationship type simultaneously to ensure the accuracy and effectiveness of the search.

[0082] ③ Calculate the matching degree and confidence score of the candidate treatment methods. For each candidate treatment method, the system comprehensively considers the results of similarity search and graph traversal to calculate the comprehensive matching degree score. The formula for calculating the matching degree score is: in, Representation and handling methods The average similarity of related similar abnormal cases Indicates the handling method Maximum propagation intensity Indicate the method of handling Historical performance evaluation score , , The weighting coefficients are satisfied. The confidence score is calculated based on evidence theory, taking into account the quantity and strength of evidence supporting the proposed treatment. The system filters cases where the match exceeds a threshold. And the confidence level exceeds the threshold The candidate treatment methods are selected to form a high-quality candidate set of treatment methods.

[0083] ④ The system integrates the anomaly cases obtained from similarity searches with the handling methods discovered through graph traversal to establish a complete reasoning chain. For each candidate handling method, the system generates a detailed reasoning report, including a list of similar anomaly cases supporting the method, a propagation path diagram, a matching degree decomposition score, and the confidence calculation process. The system also provides an applicability analysis of the handling method, including expected effects, implementation conditions, and potential risks. All reasoning processes and results are recorded in the knowledge graph, enriching the graph's reasoning history and providing more reference for subsequent searches and reasoning. The system continuously optimizes the similarity threshold and graph traversal parameters by periodically analyzing the effectiveness of the reasoning results, thereby improving the accuracy of search and reasoning.

[0084] 4) Based on the matching results and confidence assessment, an optimized handling method is generated. Multiple candidate handling schemes are weighted and fused, and adaptive adjustments are made based on the specific context of the current anomaly detection results. The final output is a handling method recommendation including operational steps, expected effects, and risk warnings. The specific implementation process is as follows: ① The candidate disposal schemes are weighted and fused. The system collects a set of candidate disposal schemes obtained through similarity search and graph traversal. Each of the disposal plans All have a matching score. and confidence score The system employs a weight-based fusion method, with weight allocation taking into account both matching degree and confidence level. The fusion weight calculation formula is as follows: in, Indicates the first The system weights the candidate solutions for fusion. It performs weighted fusion on each component of the candidate solutions, including the sequence of operation steps, parameter adjustment range, and execution timing requirements. For textual elements, a weighted text fusion algorithm is used; for numerical elements, a weighted average method is used; and for sequential elements, sequence alignment and fusion are performed based on edit distance and weights. The fusion process ensures that the advantageous elements of each candidate solution are preserved, forming a preliminary optimized solution.

[0085] ② Adaptive adjustments are made based on the specific context of the current anomaly detection results. The system analyzes the contextual features of the current anomaly detection results, including satellite operation mode, mission stage, equipment status, and historical handling records. The adaptive adjustment process establishes a mapping relationship between contextual features and handling plan parameters, achieving intelligent adjustments through a rule engine and machine learning model. Adjustment rules include parameter correction rules, step optimization rules, and condition supplementation rules. Parameter correction adjusts the numerical parameters in the handling plan based on the current environmental state; step optimization adjusts the operation sequence based on equipment availability; and condition supplementation adds necessary preventative measures based on risk assessment results. The adjustment process adopts a progressive optimization strategy, first addressing key parameters and steps, and then optimizing auxiliary elements to ensure the systematic and complete nature of the adjustment.

[0086] ③ Generate complete disposal method recommendations and evaluate their effectiveness. Based on the fusion and adjustment results, the system generates structured disposal method recommendations. The recommendations consist of three main parts: the operation steps section provides a detailed sequence of operation instructions, including the operation object, operation method, operation parameters, and execution order; the expected results section describes the desired state indicators after disposal, including the parameter recovery range, the degree of state improvement, and the expected time; and the risk warning section lists possible risk factors and countermeasures, including risk type, risk level, and emergency plan. The system evaluates the effectiveness of the generated disposal method recommendations, with evaluation indicators including feasibility score, expected results score, and risk control score. The evaluation process employs a multi-expert simulation review mechanism, using a rule engine to simulate the execution effects under different scenarios.

[0087] ④ Establish a continuous optimization mechanism for proposed treatment methods, constantly improving the quality of recommendations through feedback loops. The optimization process is based on historical execution effect data, analyzing the deviation between proposed treatment methods and actual results to identify areas for improvement. The optimization algorithm employs gradient descent-based parameter tuning and sequence editing-based step optimization, with the objective function being to minimize the difference between expected and actual results. The system also provides a verification environment for proposed treatment methods, supporting simulated execution and effect prediction. The verification process utilizes digital twin technology to test the execution process and effects of proposed treatment methods in a virtual environment, identifying potential problems and providing improvement suggestions. Verification results are fed back to the optimization stage, forming a complete quality improvement closed loop.

[0088] ⑤ Generate the final version of the proposed treatment methods, using a standardized output format to ensure readability and executability. The output includes an overview of the treatment methods, detailed operational guidelines, expected performance indicators, risk control measures, and implementation precautions. The system establishes a tracking and evaluation mechanism for the proposed treatment methods, recording the actual implementation status, effectiveness verification results, and user feedback for each suggestion. Tracking data is used to update the effectiveness evaluation scores of the treatment methods in the knowledge graph, providing a more accurate reference for subsequent similarity searches and weighted fusion. The system also provides version management functionality for the proposed treatment methods, supporting updates, rollbacks, and comparative analysis to ensure continuous improvement and optimization.

[0089] Optionally, the above technical solution also includes a diagnostic history query module. This module is used to query historical diagnostic information by spacecraft, time, and parameter code in multiple dimensions. The historical diagnostic information includes parameter names, parameter values, diagnostic information, and response operation records. The specific implementation process is as follows: 1) The diagnostic history query module features a data architecture design and storage plan. The module employs a hybrid storage architecture, distributing different types of historical diagnostic information across multiple databases. Time-series data, such as parameter names and values, is stored in an InfluxDB time-series database, sharded according to satellite number and parameter code. Text-intensive data, such as diagnostic information and response operation records, is stored in an Elasticsearch cluster with a full-text search index. Metadata and relationships are stored in a MySQL relational database to ensure data consistency and integrity. The storage structure uses a star schema, with the fact table containing core metrics for diagnostic records and dimension tables including time, spacecraft, and parameter dimensions. Each diagnostic record is assigned a globally unique identifier, generated using a combination of timestamp, satellite number, and sequence number to ensure uniqueness and timeliness.

[0090] 2) The diagnostic history query module collects and preprocesses historical diagnostic information. This module subscribes to real-time diagnostic results generated by the health diagnosis module via a message queue, and periodically synchronizes historical data from the time-series database. The data collector adopts a distributed architecture, with each collection node responsible for collecting data from a specific satellite. The collected raw data undergoes cleaning and standardization, including removing duplicate records, completing missing fields, standardizing the time format, and converting data units. The preprocessing stage also performs quality checks on parameter values, identifying and marking abnormal data points. Data enrichment technology is used during processing, querying parameter names based on parameter codes and retrieving satellite metadata based on satellite numbers to enrich the information content of the diagnostic records. The preprocessed data is distributed to the corresponding database systems according to the storage plan.

[0091] 3) The diagnostic history query module constructs a multi-dimensional query index system. The module establishes an optimized index structure for each query dimension. The spacecraft dimension index is organized according to satellite numbers, supporting queries by single satellite or satellite group. The time dimension index adopts a hierarchical structure, supporting time queries at different granularities such as year, month, day, hour, and minute. Time range queries use B+ tree indexes to achieve efficient range scanning. The parameter code dimension index establishes an inverted index of parameter codes, supporting exact matching and fuzzy queries. For composite indexes, a joint index of "spacecraft-time-parameter code" is established, covering common multi-dimensional combination query scenarios. Index updates adopt a near real-time strategy, ensuring that new diagnostic records can be queried within one minute of being entered into the database.

[0092] 4) The diagnostic history query module develops a query engine and interface services. The query engine adopts a modular design, comprising three core components: a query parser, a query optimizer, and a query executor. The query parser receives query requests from the front end, parses the query conditions, and verifies the validity of the query parameters. The query optimizer analyzes the query conditions, selects the optimal query path and indexing strategy, and generates a query execution plan. The query executor concurrently accesses multiple data storage systems, performs data retrieval operations, and merges the query results. The query interface provides a RESTful API, supporting complex combinations of query conditions. The query expression format is as follows: in, Indicates the query conditions. Represents the set of spacecraft numbers. Indicates the query start time. Indicates the query end time. Represents the set of parameter codes. This indicates other filtering conditions. The query interface also supports advanced features such as pagination parameters, sorting parameters, and selection of return fields.

[0093] 5) The Diagnostic History Query module processes and displays query results. After the query engine completes execution, the result processor merges and assembles results from different data sources. The result assembly process aligns the results according to the time sequence of the diagnostic records, ensuring accurate correspondence between parameter names, parameter values, diagnostic information, and response operation records. The module provides multiple result display formats, including list view, detail view, and statistical view. The list view displays summary information of diagnostic records and supports sorting and filtering by column. The detail view displays complete information for a single diagnostic record, including trend charts of parameter values ​​and timelines of response operation records. The statistical view provides aggregated analysis of query results, including anomaly statistics, parameter value distribution analysis, and diagnostic result classification statistics. All views support data export functionality, with export formats including CSV, Excel, and PDF.

[0094] 6) A multi-level caching architecture is adopted to improve query performance. The first-level cache uses local memory to cache the metadata corresponding to frequently accessed query conditions, while the second-level cache uses a Redis cluster to cache the result sets of commonly used queries. The cache key design includes the hash value of the query conditions, and the cache invalidation strategy is based on a combination of time-driven and event-driven approaches. For large-scale data queries, the module implements query sharding technology, automatically decomposing queries with large time ranges into multiple subqueries for parallel execution. Database queries use connection pooling and statement preprocessing to reduce network overhead and SQL parsing time. The module also provides query performance monitoring functions, recording the response time, data volume, and resource consumption of each query, providing a basis for subsequent optimization.

[0095] 7) Regularly perform data maintenance tasks, including index rebuilding, statistical updates, and data defragmentation. Historical data is stored in a tiered manner according to a time strategy: data from the most recent 3 months is stored in an online database, data from 3 months to 1 year is stored in a near-line database, and data older than 1 year is archived to an offline storage system. The archiving process maintains data queryability; when users query data across time ranges, the module automatically retrieves and integrates results from multiple storage levels. Data cleanup strategies are based on storage space and business needs, automatically cleaning up expired temporary data and duplicate records. All maintenance operations are logged in detail, supporting operation auditing and troubleshooting.

[0096] The parameter name serves as a readable identifier for spacecraft telemetry parameters, intuitively describing the physical quantity or equipment status represented by the parameter. A one-to-one correspondence is established between parameter names and parameter codes; the corresponding parameter name can be retrieved through the parameter code. Parameter names are typically described in English or Chinese and include information such as the system to which the parameter belongs, the equipment type, and the measured quantity. In the diagnostic history query module, the parameter name, as an important component of historical diagnostic information, helps users quickly understand the business meaning of the parameter. The management and maintenance of parameter names are performed in the system metadata database, ensuring the consistency and accuracy of parameter names. Updates to parameter names are synchronously reflected in historical query results, guaranteeing consistent data display.

[0097] Parameter values ​​are the specific numerical values ​​of spacecraft telemetry parameters at a particular point in time, reflecting the instantaneous state or measurement result of the parameters. Parameter values ​​include the value itself, data quality identifiers, and timestamps, and the value types include integer, floating-point, and Boolean. Parameter values ​​may contain raw measurement values, engineering transformation values, or status-coded values, the specific meaning of which is determined by the parameter definition. In the diagnostic history query module, parameter values ​​serve as the core content of historical diagnostic information, used to analyze parameter change trends and anomaly patterns. The storage of parameter values ​​considers a balance between accuracy and efficiency; important parameters store full-precision data, while general parameters store statistically aggregated data. Parameter value queries support advanced functions such as numerical range filtering and outlier identification.

[0098] The diagnostic information is a conclusive description generated by the health diagnosis module after analyzing and judging telemetry parameters. It includes elements such as the diagnostic result, abnormality level, diagnostic time, and diagnostic basis, and is generated using built-in functions of the diagnostic scripting language. Diagnostic information is categorized by severity, including normal, mildly abnormal, and severely abnormal states, each corresponding to a specific display color and prompt. In the diagnostic history query module, diagnostic information serves as a key component of historical diagnostic records, helping users understand the historical changes in the parameters' health status. Diagnostic information is stored using a combination of structured and unstructured methods, supporting both conditional filtering and full-text search. The display of diagnostic information considers readability and completeness, providing detailed diagnostic context information.

[0099] The response operation log is a complete record of the handling measures taken and their results in response to diagnosed anomalies. It includes detailed information such as operation time, operator, operation type, operation content, and operation result. Operation types include parameter adjustment, equipment restart, and mode switching, while the operation result log records the effectiveness verification information after the measures were implemented. The response operation log is derived from both manual handling and automated execution records, ensuring the traceability of the anomaly handling process. In the diagnostic history query module, the response operation log is linked to the corresponding diagnostic information, forming a complete anomaly handling closed loop. The response operation log query supports filtering by multiple conditions such as operation type, operator, and operation time, facilitating problem tracing and experience summarization.

[0100] like Figure 2 As shown in the figure, a spacecraft health management method according to an embodiment of the present invention includes the following steps: S1. Configure diagnostic rules for spacecraft telemetry data through a visual interactive interface. The diagnostic rules are written in a diagnostic scripting language, which supports data type declarations, conditional expressions, control statements, and built-in function calls. S2. Receive telemetry data from the spacecraft in real time, and perform logical judgments on the received telemetry data based on the configured diagnostic rules to generate parameter status change results and anomaly detection results.

[0101] Optionally, the above technical solution also includes: a method for recording and providing handling of query anomaly detection results, wherein the handling method includes operational suggestions from operation and maintenance experts.

[0102] Optionally, the above technical solution also includes: querying historical diagnostic information in multiple dimensions by spacecraft, time, and parameter code, whereby the historical diagnostic information includes parameter name, parameter value, diagnostic information, and response operation records.

[0103] Optionally, in the above technical solution, the parameter status change results include the status type identifier and status change time of the telemetry parameter, and the anomaly detection results include alarm level, alarm description information, solution suggestions, and recommended operation instructions.

[0104] It should be noted that the beneficial effects of the spacecraft health management method provided in the above embodiments are the same as those of the spacecraft health management system described above, and will not be repeated here. Furthermore, the methods and system embodiments provided in the above embodiments belong to the same concept, and their specific implementation processes are detailed in the system embodiments, and will not be repeated here.

[0105] An electronic device according to an embodiment of the present invention includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements any of the above-described spacecraft health management methods.

[0106] An embodiment of the present invention provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements any of the aforementioned spacecraft health management methods.

[0107] The above description is merely a preferred embodiment of the present invention and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of disclosure in this invention is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the above-disclosed concept. For example, technical solutions formed by substituting the above features with (but not limited to) technical features with similar functions disclosed in this invention.

[0108] Although embodiments of the present invention have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting the present invention. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of the present invention.

Claims

1. A spacecraft health management system, characterized in that, include: Knowledge base configuration module and health diagnosis module; The knowledge base configuration module is used to configure diagnostic rules for spacecraft telemetry data through a visual interactive interface. The diagnostic rules are written in a diagnostic scripting language that supports data type declarations, conditional expressions, control statements, and built-in function calls. The health diagnosis module is used to: receive telemetry data from the spacecraft in real time, and perform logical judgments on the received telemetry data based on the configured diagnosis rules, generating parameter status change results and anomaly detection results.

2. The spacecraft health management system according to claim 1, characterized in that, It also includes a diagnostic treatment record query module, which is used to record and provide treatment methods for querying the abnormal detection results, wherein the treatment methods include operation suggestions from operation and maintenance experts.

3. The spacecraft health management system according to claim 2, characterized in that, It also includes a diagnostic history query module, which is used to query historical diagnostic information by spacecraft, time, and parameter code in multiple dimensions. The historical diagnostic information includes parameter name, parameter value, diagnostic information, and response operation record.

4. A spacecraft health management system according to any one of claims 1 to 3, characterized in that, The parameter status change results include the status type identifier and status change time of the telemetry parameters, and the anomaly detection results include alarm level, alarm description information, solution suggestions, and recommended operation instructions.

5. A spacecraft health management method, characterized in that, include: Diagnostic rules for spacecraft telemetry data can be configured through a visual interactive interface. These diagnostic rules are written in a diagnostic scripting language that supports data type declarations, conditional expressions, control statements, and built-in function calls. The system receives telemetry data from the spacecraft in real time and performs logical judgments on the received telemetry data based on the configured diagnostic rules to generate parameter status change results and anomaly detection results.

6. The spacecraft health management method according to claim 5, characterized in that, Also includes: The system records and provides methods for handling the query results of the anomaly detection, wherein the handling methods include operational suggestions from operations and maintenance experts.

7. A spacecraft health management method according to claim 5, characterized in that, Also includes: Historical diagnostic information can be queried in multiple dimensions, including spacecraft, time, and parameter code. The historical diagnostic information includes parameter name, parameter value, diagnostic information, and response operation records.

8. A spacecraft health management method according to any one of claims 5 to 7, characterized in that, The parameter status change results include the status type identifier and status change time of the telemetry parameters, and the anomaly detection results include alarm level, alarm description information, solution suggestions, and recommended operation instructions.

9. An electronic device, characterized in that, The device includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement a spacecraft health management method according to any one of claims 5 to 8.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements a spacecraft health management method according to any one of claims 5 to 8.

Images