An aircraft health monitoring system, method, apparatus, and medium

Abstract

The embodiment of the application discloses an aircraft health monitoring system, method, equipment and medium, and solves the technical problem of poor universality of the existing aircraft health monitoring system. The system is composed of a man-machine interface, a platform management module, a rule base management module and a diagnosis monitoring module. The man-machine interface is used for information interaction between a user and the platform management module, the rule base management module and the diagnosis monitoring module. The platform management module is used for managing a model, monitoring items, fault facts and telemetry variables of a target aircraft. The rule base management module is used for managing rule script editing information and rule base sub-library information. The diagnosis monitoring module is used for managing monitoring tasks, monitoring rules, diagnosis rules and real-time monitoring data statistics.

Description

Technical Field

[0001] This application relates to the field of aircraft health monitoring technology, and in particular to an aircraft health monitoring system, method, device and medium. Background Technology

[0002] Aircraft health monitoring, based on acquired test information or real-time sensor data, employs technologies such as information processing, model discrimination, rule monitoring, and data mining to achieve anomaly detection, identification, and early warning, thereby ensuring aircraft safety performance and reducing the risk of accidents.

[0003] Currently, aircraft health monitoring is mainly achieved through aircraft health monitoring systems, but these systems have poor versatility, thus limiting their application scenarios. Summary of the Invention

[0004] This application provides an aircraft health monitoring system, method, device, and medium, which solves the technical problem of poor versatility of existing aircraft health monitoring systems.

[0005] On the one hand, embodiments of this application provide an aircraft health monitoring system, which consists of a human-machine interface, a platform management module, a rule base management module, and a diagnostic monitoring module;

[0006] The human-machine interface is used for information exchange between the user and the platform management module, rule base management module, and diagnostic monitoring module.

[0007] The platform management module connects to the human-machine interface, rule base management module, and diagnostic monitoring module; it is used to manage the target aircraft's model, monitoring items, fault facts, and telemetry variables.

[0008] The rule base management module is connected to the human-machine interface, platform management module, and diagnostic monitoring module, and is used to manage rule script editing information and rule base sub-database information.

[0009] The diagnostic monitoring module is connected to the human-machine interface, platform management module, and rule base management module, respectively, and is used to manage monitoring tasks, monitoring rules, diagnostic rules, and real-time monitoring data statistics.

[0010] As some optional implementations of this application, the platform management module includes a model management submodule, a monitoring item management submodule, a fault fact management submodule, and a telemetry variable management submodule;

[0011] The model management submodule is used to create, modify, delete, and configure protocols for the model information of the target aircraft; the model information includes model code, model name, external name, platform, and person in charge;

[0012] The monitoring item management submodule is used to add, delete, and query the project information of monitoring items; the project information includes the aircraft model, application stage, and project name;

[0013] The fault fact management submodule is used to add, delete, modify, and query fault fact attributes under a model; wherein, the fault fact attributes include fault fact name, fault description, fault mode, possible causes of fault, fault interpretation description, fault hazard, and handling countermeasures;

[0014] The telemetry variable management submodule is used to add, delete, modify, and query telemetry variable attributes for different models; wherein, the telemetry variable attributes include variable code, variable name, data type, verification range, and model.

[0015] As some optional embodiments of this application, the rule base management module includes a rule script editing submodule and a rule base sub-management submodule;

[0016] The rule script editing submodule includes file path configuration and rule logic configuration. The file path configuration loads the system rule library file path to support rule calls and nesting. The rule logic configuration includes a general function body and an editable function area. The general function body uses a fixed format to define function headers and comments, including the rule function name, rule function logic, input / output variables, and variable type information, so that the system can automatically identify the script content and display script attributes. The editable function area is used for logical editing of specific functions. Before submission, the edited rules must undergo syntax compilation checks to ensure that the generated rule file is indeed usable and can be added to the library after verification.

[0017] The rule base sub-module is used for querying, deleting, publishing, and importing and exporting files in a specified format. The storage adopts a dual storage method of database and file system.

[0018] As some optional embodiments of this application, the diagnostic monitoring module includes a task management submodule, a rule binding submodule, a diagnostic reasoning submodule, and a real-time monitoring and statistics submodule;

[0019] The task management submodule is used to add, start, stop, delete, and query diagnostic tasks.

[0020] The rule binding submodule is used to bind input telemetry variables and output fault facts to rule instances. The bound rules can be divided into threshold rules, interpretation rules, and inference rules to realize the association between monitoring rules and monitoring items.

[0021] The real-time monitoring and statistics submodule is used to monitor the execution status of each monitoring task in real time, and to perform abnormal alarms, rule status browsing, and centralized display of important rules based on the real-time monitoring information.

[0022] Furthermore, embodiments of this application provide an aircraft health monitoring method, applied to the aircraft health monitoring system described above, comprising the following steps:

[0023] Configure the platform and input target monitoring information; wherein, the target monitoring information includes the target aircraft model information, monitoring items, fault facts and telemetry data;

[0024] Based on target monitoring information, target monitoring rule information is obtained;

[0025] Based on the monitoring rule information, a monitoring task is constructed to monitor the monitoring items of the target aircraft in real time and generate real-time monitoring information.

[0026] The real-time monitoring information is then exchanged with the user through a human-machine interface.

[0027] As some optional implementations of this application, obtaining target monitoring rule information based on target monitoring information includes:

[0028] Based on the target aircraft's model information, monitoring rule information is added, and inputs and outputs are associated for the monitoring rules. The input is the platform-configured telemetry variables, and the output is the platform-configured fault facts.

[0029] As some optional implementations of this application, the step of constructing a monitoring task based on the monitoring rule information, performing real-time monitoring of the monitoring items of the target aircraft, and generating real-time monitoring information includes:

[0030] Based on the monitoring rule information, a monitoring task is constructed, and monitoring task information is obtained;

[0031] Based on the monitoring task information, the monitoring items of the target aircraft are monitored in real time, and data distribution processing, data reasoning processing and data interpretation are performed to obtain real-time monitoring information.

[0032] As some optional embodiments of this application, the step of real-time monitoring of the target aircraft's monitoring items based on the monitoring task information, and performing data distribution processing, data inference processing, and data interpretation to obtain real-time monitoring information includes:

[0033] The monitoring task information is decoded using a data receiving process to obtain first data information. After obtaining the first data information, the data distribution process and the inference engine startup process start the threshold process, the interpretation process, the inference process, the database process, and the statistics process, and distribute the telemetry data to the threshold process and the interpretation process of different tasks.

[0034] Once the threshold process and interpretation process of a certain task receive telemetry data, they begin periodic monitoring. After the current period is completed, the execution result is transmitted to the corresponding inference process. The monitoring continues until the corresponding inference process is completed and feedback information is received.

[0035] After receiving the current cycle execution results from the corresponding judgment process and threshold process, the inference process begins to monitor the inference rules and, upon completion, reports the completion of execution to the judgment process and threshold process.

[0036] When the statistics process receives the execution data from the inference process, it begins to collect the execution results and obtain real-time monitoring information. The real-time monitoring information includes the total number of executions, the number of executions per hour, the total number of failures, and the number of failures per unit time.

[0037] In another aspect, embodiments of this application provide a machine-readable storage medium storing a machine-readable program, wherein the processor executes the machine-readable program to implement the aircraft health monitoring method described above.

[0038] In another aspect, embodiments of this application provide an electronic device, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the aircraft health monitoring method described above.

[0039] Compared with the prior art, this application provides an aircraft health monitoring system, which consists of a human-machine interface, a platform management module, a rule base management module, and a diagnostic monitoring module. The human-machine interface is used for information interaction between the user and the platform management module, the rule base management module, and the diagnostic monitoring module. The platform management module is connected to the human-machine interface, the rule base management module, and the diagnostic monitoring module, and is used to manage the target aircraft's model, monitoring items, fault facts, and telemetry variables. The rule base management module is connected to the human-machine interface, the platform management module, and the diagnostic monitoring module, and is used to manage rule script editing information and rule base sub-database information. The diagnostic monitoring module is connected to the human-machine interface, the platform management module, and the rule base management module, and is used to manage monitoring tasks, monitoring rules, diagnostic rules, and real-time monitoring data statistics. As can be seen, compared with the prior art, the aircraft health monitoring system described in this application, by adopting a modular loosely coupled design and using custom function to realize the input of monitoring rules, breaks through the limitations of symbolic semantics and enhances the system's knowledge expression capability; furthermore, it separates the monitoring rules from test data and fault facts, expressing only the reasoning logic, allowing for the sharing and reuse of diagnostic knowledge for different types of aircraft, thus improving the system's versatility. This solves the technical problem of poor versatility in existing aircraft health monitoring systems. Attached Figure Description

[0040] To more clearly illustrate the technical solutions of the embodiments of this application, the drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0041] Figure 1 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application;

[0042] Figure 2 This is a schematic diagram of the structure of an aircraft health monitoring system provided in an embodiment of this application;

[0043] Figure 3 This is a schematic block diagram of the internal structure of an inference engine provided in an embodiment of this application;

[0044] Figure 4 This is a flowchart illustrating an aircraft health monitoring method provided in an embodiment of this application. Detailed Implementation

[0045] It should be understood that the specific embodiments described herein are merely illustrative of this application and are not intended to limit this application.

[0046] The main solution of this application embodiment is: an aircraft health monitoring system, comprising a human-machine interface, a platform management module, a rule base management module, and a diagnostic monitoring module; the human-machine interface is used for information interaction between the user and the platform management module, the rule base management module, and the diagnostic monitoring module; the platform management module is connected to the human-machine interface, the rule base management module, and the diagnostic monitoring module respectively, and is used to manage the target aircraft's model, monitoring items, fault facts, and telemetry variables; the rule base management module is connected to the human-machine interface, the platform management module, and the diagnostic monitoring module respectively, and is used to manage rule script editing information and rule base sub-database information; the diagnostic monitoring module is connected to the human-machine interface, the platform management module, and the rule base management module respectively, and is used to manage monitoring tasks, monitoring rules, diagnostic rules, and real-time monitoring data statistics.

[0047] Aircraft health monitoring, based on acquired test information or real-time sensor data, employs technologies such as information processing, model discrimination, rule monitoring, and data mining to achieve anomaly detection, identification, and early warning, thereby ensuring aircraft safety performance and reducing the risk of accidents.

[0048] Expert systems, due to their simplicity, effectiveness, ease of understanding, and ease of implementation, have gradually become one of the important means of aircraft health monitoring. Their implementation mainly includes knowledge base construction and inference engine design. Specifically, this involves transforming common model design data, expert experience, and other knowledge into monitoring rules through symbolic semantics and storing them in a database. During monitoring, real-time data is loaded into the inference engine, and through an efficient reasoning mechanism, it determines whether the aircraft is abnormal.

[0049] With the rapid development of aerospace technology, there are now numerous aircraft models and increasingly complex systems, making it difficult for existing aircraft health monitoring expert systems to meet real-world needs. The main shortcomings include:

[0050] 1) Poor versatility leads to low reusability and reuse, making it difficult to reuse expert systems on different platform models;

[0051] 2) Knowledge representation encounters bottlenecks; the system's normative semantics struggle to express complex system knowledge.

[0052] 3) The real-time performance is not high. The test data of the aircraft increases sharply, and the inference engine is unable to meet the real-time performance indicators.

[0053] 4) The application scenarios are limited, often only for the operation and maintenance of aircraft, and rarely involve system design, production testing, etc.

[0054] To address the aforementioned issues, this application provides a generalized aircraft health monitoring expert system. This system integrates open expert knowledge input, modular knowledge management, efficient rule reasoning, and user-friendly execution monitoring, enabling effective real-time health monitoring of various aircraft models.

[0055] Reference Figure 1 , Figure 1 This is a schematic diagram of the electronic device structure of the hardware operating environment involved in the embodiments of this application.

[0056] like Figure 1 As shown, the electronic device may include: a processor 1001, such as a central processing unit (CPU), a communication bus 1002, a user interface 1003, a network interface 1004, and a memory 1005. The communication bus 1002 is used to enable communication between these components. The user interface 1003 may include a display screen or an input unit such as a keyboard; optionally, the user interface 1003 may also include a standard wired interface or a wireless interface. The network interface 1004 may optionally include a standard wired interface or a wireless interface (such as a Wi-Fi interface). The memory 1005 may be a high-speed random access memory (RAM) or a stable non-volatile memory (NVM), such as a disk drive. The memory 1005 may also optionally be a storage device independent of the aforementioned processor 1001.

[0057] Those skilled in the art will understand that Figure 1 The structure shown does not constitute a limitation on the electronic device and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0058] like Figure 1 As shown, the memory 1005, which serves as a storage medium, may include an operating system, a network communication module, a user interface module, and electronic programs.

[0059] exist Figure 1 In the electronic device shown, the network interface 1004 is mainly used for data communication with the network server; the user interface 1003 is mainly used for data interaction with the user; the processor 1001 and the memory 1005 in the electronic device of this application can be set in the electronic device, and the electronic device calls the aircraft health monitoring system stored in the memory 1005 through the processor 1001 and executes the aircraft health monitoring method provided in the embodiment of this application.

[0060] This application provides an aircraft health monitoring system comprising a human-machine interface, a platform management module, a rule base management module, and a diagnostic monitoring module. The human-machine interface facilitates information exchange between the user and the platform management module, rule base management module, and diagnostic monitoring module. The platform management module is connected to the human-machine interface, rule base management module, and diagnostic monitoring module, and manages the target aircraft's model, monitoring items, fault facts, and telemetry variables. The rule base management module, connected to the human-machine interface, platform management module, and diagnostic monitoring module, manages rule script editing information and rule base sub-database information. The diagnostic monitoring module, connected to the human-machine interface, platform management module, and rule base management module, manages monitoring tasks, monitoring rules, diagnostic rules, and real-time monitoring data statistics.

[0061] In other words, the main business functions of the system include three parts: platform management, rule base management, and diagnostic monitoring. Platform management is used to manage the monitoring projects established within the system, the fault facts of the corresponding models, telemetry variables, and model information; rule base management enables scripted rule editing, input, and storage in separate databases; and diagnostic monitoring is responsible for rule binding, diagnostic reasoning, and anomaly alarms.

[0062] The platform management includes management of model, monitoring items, fault facts, and telemetry forms. The model form contains aircraft model information; the monitoring item form contains all test items under a specific model; the fault fact form contains possible fault modes of the model; and the telemetry form contains real-time data telemetry variable information, supporting variable threshold settings.

[0063] The rule base management includes rule editing and sub-database management. Rule editing supports online programming, allowing users to customize and build rule functions according to a fixed format, and supports nested rules. Before submission to the database, the system performs an edit check. The rule base is divided into a shared rule base and a model rule base. Rules in the shared rule base can be used for monitoring all models, while rules in the model rule base are specific to a particular model. Rules in the base are categorized as published or pending publication. Published rules can be used for rule binding, while pending publication indicates that the rule is still under editing. Rule base management supports rule querying, deletion, publishing, and importing / exporting files in a specified format.

[0064] The diagnostic monitoring system includes task management, rule binding, diagnostic inference, and real-time monitoring. Task management controls the execution of monitoring items for each model; rule binding establishes the interface association for published rules, binding telemetry variables as input and binding fault facts as output, adding them to the threshold rules, interpretation rules, and inference rules tables corresponding to the defined monitoring items according to their characteristics; diagnostic inference is used for real-time rule inference, including data distribution and inference engine startup processes, data receiving processes, threshold processes, interpretation processes, inference processes, database processes, and statistical processes, employing multi-process concurrent execution to achieve real-time data reception and distribution, real-time interpretation of diagnostic rules, storage of abnormal results in the database, and statistical analysis of the inference process; real-time monitoring displays the execution status of each task, supports abnormal alarms, rule status browsing, and centralized display of important rules.

[0065] Specifically, the platform management module includes a model management submodule, a monitoring item management submodule, a fault fact management submodule, and a telemetry variable management submodule. The model management submodule is used to create, modify, delete, and configure protocols for the target aircraft's model information; the model information includes model code, model name, external name, affiliated platform, and responsible person. The monitoring item management submodule is used to add, delete, and query monitoring item information; the item information includes the aircraft's model, application stage, and project name. The fault fact management submodule is used to add, delete, modify, and query fault fact attributes under a model; the fault fact attributes include fault fact name, fault description, fault mode, possible causes of the fault, fault interpretation description, fault hazard, and handling countermeasures. The telemetry variable management submodule is used to add, delete, modify, and query telemetry variable attributes under different models; the telemetry variable attributes include variable code, variable name, data type, verification interval, and affiliated model.

[0066] Specifically, the rule base management module includes a rule script editing submodule and a rule base sub-database management submodule. The rule script editing submodule includes file path configuration and rule logic configuration. The file path configuration loads the system rule base file path to support rule calls and nesting. The rule logic configuration includes a general function body and an editable function area. The general function body uses a fixed format to define function headers and comments, including the rule function name, rule function logic, input and output variables, and variable type information, so that the system can automatically identify the script content and display the script attributes. The editable function area is used to implement the logic editing of specific functions. Before submission, the edited rules must undergo syntax compilation checks to ensure that the generated rule files are indeed usable and can be added to the database after verification. The rule base sub-database management submodule is used for querying, deleting, publishing, and importing and exporting files in a specified format. Storage adopts a dual storage method of database and file system.

[0067] Specifically, the diagnostic monitoring module includes a task management submodule, a rule binding submodule, a diagnostic reasoning submodule, and a real-time monitoring and statistics submodule. The task management submodule is used to add, start, stop, delete, and query diagnostic tasks. The rule binding submodule is used to bind input telemetry variables and output fault facts to rule instances. The bound rules can be divided into threshold rules, interpretation rules, and reasoning rules to associate monitoring rules with monitoring items. The real-time monitoring and statistics submodule is used to monitor the execution status of each monitoring task in real time and, based on the real-time monitoring information, perform abnormal alarms, rule status browsing, and centralized display of important rules.

[0068] In some alternative implementations, the aircraft health monitoring system described in this application embodiment can be as follows: Figure 2 As shown, it mainly includes three modules: platform management, rule base management, and diagnostic monitoring.

[0069] The platform management module includes model management, monitoring item management, fault fact management, and telemetry variable management.

[0070] 1) Model management supports the creation, modification, deletion, and configuration of protocols for aircraft equipment models. Model information includes model code, model name, external name, platform, and responsible person.

[0071] 2) Monitoring item management allows for adding, deleting, and querying monitoring items. Item information includes the model, application stage, and project name, and the inclusion relationship is displayed in a structure tree format.

[0072] 3) Fault Fact Management allows for adding, deleting, modifying, and querying fault facts under a specific model. Fault fact attributes include fault fact name, fault description, fault mode, possible causes of the fault, fault interpretation description, fault hazard, and handling countermeasures.

[0073] 4) Telemetry variable management allows for adding, deleting, modifying, and querying telemetry variables for different models. Telemetry variables can be imported one by one manually or in batches through the automatic synchronization function. Telemetry variable attributes include variable code, variable name, data type, verification range, and model.

[0074] Rule base management mainly includes rule script editing and rule base sub-database management:

[0075] 1) Script rule editing can be done using languages ​​such as Python. The editing area is divided into two parts: file path configuration and rule logic implementation. File path configuration loads the system rule library file path to support rule calls and nesting. Rule logic implementation includes a general function body and an editable function area. The general function body uses a fixed format to define the function header and comments, including the rule function name, rule function logic, input and output variables, and variable type information, so that the system can automatically recognize the script content and display the script attributes. The editable function area is used to edit the logic for implementing specific functions. Before submitting the edited rules, a syntax compilation check must be performed to ensure that the generated rule file is indeed usable and can be added to the library after it is error-free.

[0076] 2) The rule base is divided into a model rule base and a shared rule base. Rules in the shared rule base support health monitoring for all models, while rules in the model rule base are only for specific models. The status of rules in the base is divided into published and pending publication. After publication, rules can be used for rule binding. Pending publication means that the rules are still being edited. The rule base management supports querying, deleting, publishing, and importing and exporting files in a specified format. Storage adopts a dual storage method of database and file system.

[0077] Diagnostic monitoring mainly includes functions such as task management, rule binding, diagnostic inference, and real-time monitoring statistics.

[0078] 1) Task management allows for adding, starting, stopping, deleting, and querying diagnostic tasks. Adding a task mainly depends on the monitoring items required for the model added during platform management. After starting a task, the server receives the start command and starts the inference engine to perform health monitoring.

[0079] 2) Rule binding completes the association between rules and monitoring items, binding input telemetry variables and output fault facts to rule instances. The bound rules can be divided into threshold rules, interpretation rules, and inference rules. Threshold rules determine whether actual data is within the normal range; interpretation rules determine whether actual telemetry parameters conform to specific patterns; and inference rules determine whether a specific logical relationship is met based on the inference results of the threshold and interpretation rules.

[0080] 3) Real-time monitoring displays the execution status of each task in a list, supporting anomaly alarms, rule status browsing, and centralized display of important rules. Anomaly alarms provide real-time information including the time of the anomaly, triggering rule, telemetry variables, outlier values, monitored items, and fault details. The rule status view displays all rules under the current diagnostic task, highlighting the rules that triggered the anomalies. Since a large number of rules may exceed the current screen's display area, key rules need to be displayed centrally.

[0081] The diagnostic reasoning described above is implemented by an inference engine for real-time rule-based reasoning. The internal structure diagram of the inference engine is shown below. Figure 3As shown in the diagram. Arrows represent information flow, the reduced-angle rectangles represent Redis cached information, and the right-angle rectangles represent inference engine processes. To meet real-time requirements, the inference engine employs multi-task concurrent execution and multi-process collaborative monitoring. Process communication uses Redis communication to monitor the dynamic data of each process in real time, improving response speed. Specifically:

[0082] 1) The inference engine process includes the data distribution process and the inference engine startup process, which are responsible for starting the entire inference engine and distributing the data received by the data receiving process;

[0083] 2) The data receiving process receives telemetry data from the aircraft;

[0084] 3) Threshold processes execute threshold rules;

[0085] 4) The judgment process executes the judgment rules;

[0086] 5) The reasoning process executes the reasoning rules;

[0087] 6) The database process stores the diagnostic results in the database;

[0088] 7) The statistics process is responsible for collecting various execution result data for statistical analysis.

[0089] Based on the same inventive concept, embodiments of this application also provide an aircraft health monitoring method, applied to the aforementioned aircraft health monitoring system, comprising the following steps:

[0090] Step S10: Configure the platform and enter the target monitoring information; wherein, the target monitoring information includes the target aircraft model information, monitoring items, fault facts and telemetry data.

[0091] It should be noted that the target aircraft refers to the aircraft that needs to be monitored.

[0092] Step S20: Obtain target monitoring rule information based on target monitoring information.

[0093] It should be noted that obtaining target monitoring rule information based on target monitoring information includes: adding monitoring rule information based on the target aircraft model information, and associating inputs and outputs for the monitoring rules. The inputs are platform-configured telemetry variables, and the outputs are platform-configured fault facts.

[0094] Step S30: Based on the monitoring rule information, construct a monitoring task, perform real-time monitoring of the monitoring items of the target aircraft, and generate real-time monitoring information.

[0095] It should be noted that the step of constructing a monitoring task based on the monitoring rule information, performing real-time monitoring of the monitoring items of the target aircraft, and generating real-time monitoring information includes: constructing a monitoring task based on the monitoring rule information and obtaining monitoring task information; performing real-time monitoring of the monitoring items of the target aircraft based on the monitoring task information, and performing data distribution processing, data reasoning processing, and data interpretation to obtain real-time monitoring information.

[0096] Furthermore, the real-time monitoring of the target aircraft's monitoring items based on the monitoring task information, and the data distribution processing, data inference processing, and data interpretation to obtain real-time monitoring information, includes: using a data receiving process to decode the monitoring task information using a decoding protocol to obtain first data information; after obtaining the first data information, the data distribution process and the inference engine startup process start a threshold process, an interpretation process, an inference process, a database process, and a statistics process, and distribute telemetry data to the threshold processes and interpretation processes of different tasks; when the threshold process and interpretation process of a certain task receive telemetry data... Afterwards, periodic monitoring begins; upon completion of the current period, the execution result is transmitted to the corresponding inference process, and monitoring continues until the corresponding inference process completes its execution and receives feedback information, then the next round of monitoring continues; after receiving the current period execution result from the corresponding judgment process and threshold process, the inference process begins monitoring the inference rules, and upon completion, sends feedback to the judgment process and threshold process that the execution is complete; when the statistics process receives the execution data from the inference process, it begins to statistically analyze the execution results and obtain real-time monitoring information; wherein, the real-time monitoring information includes the total number of executions, the number of executions per hour, the total number of failures, and the number of failures per unit time.

[0097] Step S40: The real-time monitoring information is exchanged with the user through a human-machine interface.

[0098] like Figure 4 As shown below, the monitoring method described in this application will be described in detail with reference to specific embodiments, so that those skilled in the art can better understand the technical solution described in this application.

[0099] Example 1

[0100] Step 1: Start and log in to the expert system;

[0101] Step 2: Configure the platform and enter the aircraft model information, monitoring items, fault facts, and telemetry data;

[0102] Step 3: Enter and manage script rules, write monitoring rules, and store them in the database;

[0103] Step 4: Complete rule binding. Add monitoring rules under the specific model monitoring item, and associate inputs and outputs for the rules. The inputs are telemetry variables configured for the platform, and the outputs are fault facts configured for the platform.

[0104] Step 5: Create a monitoring task and add monitoring items;

[0105] Step 6: Start the monitoring task, supporting multi-task concurrent monitoring. The specific monitoring inference process is as follows:

[0106] Step 6.1: Start the inference engine. The server transmits task information to the data receiving process, data distribution process and inference engine startup process through Redis. The data receiving process parses the telemetry data decoding protocol and transmits the received telemetry data to the data distribution process and inference engine startup process.

[0107] Step 6.2: Data Distribution Process and Inference Engine Startup Process After receiving the task information and telemetry data, the threshold process, interpretation process, inference process, database process and statistics process are started accordingly, and the telemetry data is distributed to the threshold process and interpretation process of different tasks.

[0108] Step 6.3: When the threshold process and interpretation process of a certain task receive telemetry data, they start periodic monitoring; after the current cycle is completed, the execution result is transmitted to the corresponding inference process until the corresponding inference process is completed and feedback information is received, then the next round of monitoring continues;

[0109] Step 6.4: After receiving the current cycle execution results from the corresponding judgment process and threshold process, the inference process begins to monitor the inference rules. After execution is completed, it reports the completion of execution to the judgment process and threshold process.

[0110] Step 6.5: When the statistics process receives the execution data from the inference process, it begins to count the execution results, including the total number of executions, the number of executions per hour, the total number of failures, and the number of failures per unit time.

[0111] Step 6.6: The database receiving process is responsible for storing abnormal results in the database to facilitate historical data analysis and statistics. When it receives abnormal data from the inference process, it starts the storage operation and sends abnormal information to the human-machine interface at the same time.

[0112] Step 7: Manually end the task or, after the task is completed, end the monitoring task. The specific process is as follows:

[0113] Step 7.1: The data receiving process stops receiving data for this task, and the data distribution process and the inference engine startup process inform the threshold process and the judgment process of the task completion information through the cache queue, and stop the data distribution of the current diagnostic task;

[0114] Step 7.2: After receiving the task termination information from the data distribution and inference engine startup process, the specific threshold process and the judgment process will exit after completing the current cycle monitoring, and at the same time send the termination information to the inference process through the cache queue.

[0115] Step 7.3: After receiving the task termination information from the corresponding threshold process and the judgment process, the specific inference process completes the current round of inference, transmits the executed diagnostic results and termination information to the database process through the queue, and then exits. If there are still tasks to execute, it returns and waits for the next task to finish; if there are no tasks to execute, it executes step 7.4.

[0116] Step 7.4: After receiving the termination message from the last inference process, the database process will exit after storing the remaining data in the database.

[0117] Step 7.5: After the database process is detected to have exited, the remaining data receiving process, data distribution process, inference engine startup process, and statistics process will exit in sequence; health monitoring ends.

[0118] It can be seen that, compared with the existing technology, the technical solution described in this application has the following advantages: 1) Monitoring rules are separated from test data and fault facts, only expressing reasoning logic, which allows for knowledge sharing and reuse for different aircraft models, improving the system's generalization level. 2) A modular loosely coupled design is adopted, and custom function functions are used to input monitoring rules, breaking through the limitations of symbolic semantics and enhancing the system's knowledge expression capabilities. 3) Multi-task concurrent execution is supported. The inference engine adopts a multi-process mechanism, with each process being independent according to its function, ensuring the real-time nature of monitoring results. Redis communication is used between processes, which can monitor the dynamic data of each process in real time and improve the refresh frequency of the interactive interface. 4) It can cover the entire life cycle of the model, with a wider range of application scenarios. In the stages of model assembly functional testing, performance testing, flight testing, operation monitoring, diagnosis and maintenance, etc., a set of monitoring items oriented to the scenario can be automatically formed based on health monitoring needs using rule functions. At the same time, centralized management of monitoring records at each stage is also conducive to model anomaly analysis, problem tracing, and design optimization.

[0119] It should be noted that the aircraft health monitoring method in this embodiment is based on the aircraft health monitoring system in the aforementioned embodiment. Therefore, the specific implementation method and the technical effects achieved in this embodiment can be referred to the implementation method of the aforementioned aircraft health monitoring system. Here, we will not elaborate on the specific modules in the system.

[0120] Furthermore, in one embodiment, this application also provides an electronic device, the electronic device including a processor, a memory, and an acquisition machine program stored in the memory, the acquisition machine program being executed by the processor to implement the steps of the method in the foregoing embodiments.

[0121] In addition, in one embodiment, this application also provides an acquisition machine storage medium, on which an acquisition machine program is stored, and the acquisition machine program is executed by a processor to implement the steps of the method in the foregoing embodiments.

[0122] In some embodiments, the machine-readable storage medium may be a memory such as FRAM, ROM, PROM, EPROM, EEPROM, flash memory, magnetic surface memory, optical disk, or CD-ROM; or it may be a device including one or any combination of the above-mentioned memories. The acquisition machine may be a variety of acquisition devices, including smart terminals and servers.

[0123] In some embodiments, executable instructions may take the form of a program, software, software module, script, or code, written in any form of programming language (including compiled or interpreted languages, or declarative or procedural languages), and may be deployed in any form, including as a standalone program or as a module, component, subroutine, or other unit suitable for use in the acquisition environment.

[0124] As an example, executable instructions may, but do not necessarily, correspond to files in a file system. They may be stored as part of a file that holds other programs or data, for example, in one or more scripts in a Hyper Text Markup Language (HTML) document, in a single file dedicated to the program in question, or in multiple collaborating files (e.g., a file that stores one or more modules, subroutines, or code sections).

[0125] As an example, executable instructions can be deployed to execute on a single acquisition device, or on multiple acquisition devices located at one location, or on multiple acquisition devices distributed across multiple locations and interconnected via a communication network.

[0126] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or system that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or system. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or system that includes that element.

[0127] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0128] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This acquisition machine software product is stored in a storage medium (such as read-only memory / random access memory, magnetic disk, optical disk), and includes several instructions to cause a multimedia terminal device (which may be a mobile phone, acquisition machine, television receiver, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0129] The above-disclosed embodiments are merely partial examples of this application and should not be construed as limiting the scope of this application. Those skilled in the art will understand that implementing all or part of the above embodiments and making equivalent changes in accordance with the claims of this application are still within the scope of the invention.

Claims

1. An aircraft health monitoring system, characterized in that, It consists of a human-machine interface, a platform management module, a rule base management module, and a diagnostic monitoring module; The human-machine interface is used for information exchange between the user and the platform management module, rule base management module, and diagnostic monitoring module. The platform management module connects to the human-machine interface, rule base management module, and diagnostic monitoring module; it is used to manage the target aircraft's model, monitoring items, fault facts, and telemetry variables. The rule base management module is connected to the human-machine interface, platform management module, and diagnostic monitoring module, and is used to manage rule script editing information and rule base sub-database information. The diagnostic monitoring module is connected to the human-machine interface, platform management module, and rule base management module, respectively, and is used to manage monitoring tasks, monitoring rules, diagnostic rules, and real-time monitoring data statistics. When using the aforementioned aircraft health monitoring system to perform aircraft health monitoring, the following steps are performed: Configure the platform and input target monitoring information; wherein, the target monitoring information includes the target aircraft model information, monitoring items, fault facts and telemetry data; Based on target monitoring information, target monitoring rule information is obtained; Based on the monitoring rule information, a monitoring task is constructed to obtain monitoring task information. A data receiving process decodes the monitoring task information using a decoding protocol to obtain first data information. After obtaining the first data information, the data distribution process and the inference engine startup process start a threshold process, a judgment process, an inference process, a database process, and a statistics process, and distribute telemetry data to the threshold processes and judgment processes of different tasks. When the threshold process and judgment process of a task receive telemetry data, they begin periodic monitoring. After the current period is completed, the execution result is transmitted to the corresponding inference process until the corresponding inference process completes execution and receives feedback information, then the next round of monitoring continues. After receiving the current period execution result from the corresponding judgment process and threshold process, the inference process begins monitoring the inference rules. After execution, it reports the completion of execution to the judgment process and threshold process. When the statistics process receives the execution data from the inference process, it begins to statistically analyze the execution results to obtain real-time monitoring information. The real-time monitoring information includes the total number of executions, the number of executions per hour, the total number of failures, and the number of failures per unit time. The real-time monitoring information is then exchanged with the user through a human-machine interface.

2. The aircraft health monitoring system according to claim 1, characterized in that, The platform management module includes a model management submodule, a monitoring item management submodule, a fault fact management submodule, and a telemetry variable management submodule; The model management submodule is used to create, modify, delete, and configure protocols for the model information of the target aircraft; the model information includes model code, model name, external name, platform, and person in charge; The monitoring item management submodule is used to add, delete, and query the project information of monitoring items; the project information includes the aircraft model, application stage, and project name; The fault fact management submodule is used to add, delete, modify, and query fault fact attributes under a model; wherein, the fault fact attributes include fault fact name, fault description, fault mode, possible causes of fault, fault interpretation description, fault hazard, and handling countermeasures; The telemetry variable management submodule is used to add, delete, modify, and query telemetry variable attributes for different models; wherein, the telemetry variable attributes include variable code, variable name, data type, verification range, and model.

3. The aircraft health monitoring system according to claim 1, characterized in that, The rule base management module includes a rule script editing submodule and a rule base sub-management submodule; The rule script editing submodule includes file path configuration and rule logic configuration. The file path configuration loads the system rule library file path to support rule calls and nesting. The rule logic configuration includes a general function body and an editable function area. The general function body uses a fixed format to define function headers and comments, including the rule function name, rule function logic, input / output variables, and variable type information, so that the system can automatically identify the script content and display script attributes. The editable function area is used for logical editing of specific functions. Before submission, the edited rules must undergo syntax compilation checks to ensure that the generated rule file is indeed usable and can be added to the library after verification. The rule base sub-module is used for querying, deleting, publishing, and importing and exporting files in a specified format. The storage adopts a dual storage method of database and file system.

4. The aircraft health monitoring system according to claim 1, characterized in that, The diagnostic monitoring module includes a task management submodule, a rule binding submodule, a diagnostic reasoning submodule, and a real-time monitoring and statistics submodule. The task management submodule is used to add, start, stop, delete, and query diagnostic tasks; The rule binding submodule is used to bind input telemetry variables and output fault facts to rule instances. The bound rules can be divided into threshold rules, interpretation rules, and inference rules to realize the association between monitoring rules and monitoring items. The real-time monitoring and statistics submodule is used to monitor the execution status of each monitoring task in real time, and to perform abnormal alarms, rule status browsing, and centralized display of important rules based on the real-time monitoring information.

5. A method for monitoring the health of an aircraft, characterized in that, The system applied to the aircraft health monitoring system as described in any one of claims 1-4 includes the following steps: Configure the platform and input target monitoring information; wherein, the target monitoring information includes the target aircraft model information, monitoring items, fault facts and telemetry data; Based on target monitoring information, target monitoring rule information is obtained; Based on the monitoring rule information, a monitoring task is constructed to obtain monitoring task information. A data receiving process decodes the monitoring task information using a decoding protocol to obtain first data information. After obtaining the first data information, the data distribution process and the inference engine startup process start a threshold process, a judgment process, an inference process, a database process, and a statistics process, and distribute telemetry data to the threshold processes and judgment processes of different tasks. When the threshold process and judgment process of a task receive telemetry data, they begin periodic monitoring. After the current period is completed, the execution result is transmitted to the corresponding inference process until the corresponding inference process completes execution and receives feedback information, then the next round of monitoring continues. After receiving the current period execution result from the corresponding judgment process and threshold process, the inference process begins monitoring the inference rules. After execution, it reports the completion of execution to the judgment process and threshold process. When the statistics process receives the execution data from the inference process, it begins to statistically analyze the execution results to obtain real-time monitoring information. The real-time monitoring information includes the total number of executions, the number of executions per hour, the total number of failures, and the number of failures per unit time. The real-time monitoring information is then exchanged with the user through a human-machine interface.

6. The aircraft health monitoring method according to claim 5, characterized in that, The process of obtaining target monitoring rule information based on target monitoring information includes: Based on the target aircraft's model information, monitoring rule information is added, and inputs and outputs are associated for the monitoring rules. The input is the platform-configured telemetry variables, and the output is the platform-configured fault facts.

7. An electronic device, characterized in that, The electronic device includes a memory and a processor, wherein the memory stores a computer program and the processor executes the computer program to implement the aircraft health monitoring method as described in any one of claims 5-6.

8. A computer-readable storage medium storing a computer program, wherein a processor executes the computer program to implement the aircraft health monitoring method as described in any one of claims 5-6.

Images