Intelligent diagnosis system and method for aero-engine

Abstract

The invention belongs to the technical field of aero-engine health management, and particularly relates to an intelligent diagnosis system and method for an aero-engine. Comprising an engine, a multi-physical field sensor network installed on the engine, a real-time feature extraction module deployed at an edge computing node, a central diagnosis server integrated with a machine learning engine, and a historical knowledge base for storing structured fault cases and health management. Through the diagnosis mechanism, the health condition of the engine is monitored in real time, and the fault diagnosis efficiency is improved by more than 50%.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of aero-engine health management, in particular to an aero-engine intelligent diagnosis system and method. BACKGROUND

[0002] As the core power device of the aircraft, the running state of the aero-engine directly determines the flight safety and operational economy, and is an important symbol of national scientific and technological strength and industrial level. With the increasing of the structural integration of the engine and the increasingly harsh service environment (high temperature, high pressure, high speed), the fault diagnosis faces multiple technical challenges: first, the quality of the monitoring data is limited due to the harsh test conditions - the on-board sensors are constrained by weight and space, the number of measurement points is limited, and the signal-to-noise ratio is extremely low (often less than 5dB) after multi-path transmission, and traditional filtering methods are difficult to effectively remove the aerodynamic and combustion interference signals; second, the difficulty of fault feature extraction is aggravated by the coupling of multiple physical fields, and in the transition state (such as acceleration and deceleration process), the interaction of gas-thermal-solid-acoustic multi-fields makes the fault feature present strong nonlinearity, and the existing gas path analysis method (such as Kalman filter) is prone to convergence failure when the parameters are insufficient, and the recognition rate of early minor faults is less than 70%; third, the adaptability of the diagnosis system is insufficient, and the performance of the same algorithm is significantly different under different conditions, for example, the recognition rate of bearing fault under steady state can reach 90%, but the false positive rate under transition state rises to more than 15%, which cannot meet the monitoring needs of the whole task profile. To solve the above problems, the prior art proposes various improvement schemes: Chen Daguang of Beijing University of Aeronautics and Astronautics proposes a multi-state gas path analysis method, which improves the convergence by increasing the number of steady-state points, but does not involve transition state signal processing; Huang Jinquan et al. use neural network to fuse gas path parameters, but ignore the mechanical fault features in vibration signals; Zhulong system of Zhongxin introduces deep spatio-temporal convolution network, which improves the recognition accuracy, but does not design a special noise reduction module for low signal-to-noise ratio signals, and the false positive rate is still higher than 3% under extreme conditions. In summary, the existing technology has not yet broken through the core bottleneck of "low signal-to-noise ratio signal fault feature extraction precision under multi-physical field coupling", resulting in problems such as response lag, high false positive rate and early fault missed detection in the engineering application of the diagnosis system, and it is necessary to develop an intelligent diagnosis technology with self-adaptive signal processing capability. SUMMARY

[0003] In order to make up for the deficiencies of the prior art and solve the above technical problems, the present application proposes an aero-engine intelligent diagnosis system and method.

[0004] The technical solution adopted by the present application to solve its technical problems is: an aero-engine intelligent diagnosis system according to the present application, comprising an engine and a multi-physical field sensor network installed on the engine, a real-time feature extraction module deployed on an edge computing node, a central diagnosis server integrated with a machine learning engine, and a historical knowledge base storing structured fault cases and health management; The multi-physical field sensor network includes deployed engine rotors, turbine blades, lubrication systems, air intake and exhaust passages, responsible for collecting vibration, oil pressure / temperature, air intake pressure / temperature, exhaust gas temperature (EGT), air path pressure ratio, etc. Data.

[0005] Preferably, the real-time feature extraction module includes an edge computing unit, envelope spectrum analysis, resonance demodulation technology and data compression.

[0006] Preferably, the central diagnostic server runs a three-layer processing architecture including: Feature fusion layer: concatenating multi-sensor feature vectors into a 32-dimensional input matrix; Fault classification model: XGBoost-based ensemble learning algorithm (200 decision trees, depth=8); Knowledge graph engine: build a fault-reason-measure association network with Neo4j.

[0007] Preferably, the historical knowledge base adopts SAEARP926 standard coding (e.g. F1001 = surge), including storing triples: vibration spectrum peak @ 800Hz, fuel regulating valve jamming and replacing valve core + cleaning oil circuit, and supporting cosine similarity retrieval, supporting case reuse mechanism based on similarity retrieval, supporting engine health real-time data storage function.

[0008] Preferably, it also includes a human-computer interaction device, which adopts a push hierarchical alarm strategy, Level 1 (yellow): suggest next stage inspection; Level 2 (red): immediately stop for repair (associated with repair manual chapter).

[0009] The intelligent diagnosis method of the aero-engine, the method is suitable for the intelligent diagnosis system of the aero-engine, and comprises the following steps: S1: Real-time acquisition of engine working condition data and extraction of time-frequency domain features; S2: Match the preset fault mode through the fault classification model; S3: Call the knowledge graph to generate a solution and push it to the terminal; S4: Store the new fault case in the knowledge base and optimize the model.

[0010] Preferably, the matching in step S2 includes the following process: a: Feature vector standardization: input the 32-dimensional feature vector uploaded by the edge computing unit, adopt Z-score normalization (based on historical training set μ, σ) to eliminate dimensional difference, output standardized feature vector with uniform numerical range, adapt to subsequent model input requirements; b: Fault type determination: high confidence confirmation: if the Top1 fault probability output by the XGBoost model is greater than the preset threshold (such as 0.85), the fault type is directly confirmed; low confidence voting: if the probability is less than or equal to the threshold, the backup models such as random forest and lightweight neural network are called, and the final fault type is confirmed according to the rule of "the most frequent occurrence + the highest probability mean"; c: Solution generation: based on the confirmed fault code (in accordance with the SAE ARP926 standard), the "fault-cause-measure" associated data is retrieved through the Neo4j knowledge graph engine, the similar degree > 0.85 of the historical effective scheme is preferentially reused, and the structured scheme containing the fault cause, maintenance steps and reference manual chapter is output; d: Result pushing and feedback: the hierarchical alarm (Level 1 yellow suggestion for checking, Level 2 red immediate shutdown) and the solution are pushed to the man-machine interaction device according to the fault severity; the engineer maintenance verification result (diagnosis correctness, scheme effectiveness) is collected and fed back to the historical knowledge base, and the closed-loop self-learning is triggered.

[0011] The intelligent diagnosis knowledge base updating method of the aero-engine, the method is suitable for the intelligent diagnosis system or the diagnosis method of the aero-engine described in any one of the above, and comprises the following steps: T1: Real-time acquisition of multi-source data; T2: Data preprocessing and standardization (data cleaning, formatting, anonymization); T3: Feature extraction and knowledge mining (fault feature extraction, association rule mining); T4: New knowledge judgment: T4.1: Confirm new knowledge: include the knowledge base to be audited (additional confidence and source), formally integrate and version release (update the production environment knowledge base); T4.2: Conflict or uncertainty: start expert audit process (man-machine cooperative research and judgment); T5: Application feedback and effect tracking (diagnosis result, maintenance work order verification).

[0012] Preferably, the new knowledge judgment of step T4 comprises novelty detection, and the newly mined mode, rule and existing knowledge base are compared in similarity. If the matching degree is lower than the threshold, it is determined that the new knowledge is "potential new knowledge", and the conflict or uncertainty includes the logical contradiction between the new knowledge and the existing knowledge.

[0013] The present application has the advantages of: 1. The present application is an edge-cloud collaborative architecture, the edge layer extracts bearing fault features through resonance demodulation technology, so that the signal-to-noise ratio is improved by 20dB, and the cloud layer retrieves the knowledge graph path based on fault probability, so that the response time is less than 200ms; 2. The application is an automatic evolution diagnosis model. When the number of new cases of a certain fault is greater than 50, the feature weight is automatically increased through dynamic weight adjustment. Through TransferLearning, the knowledge of CFM56 engine is transferred to LEAP engine to realize cross-engine knowledge transfer and reuse similar cases. 3. The application uses a diagnosis system composed of a multi-physical field sensor network, a real-time feature extraction module, a central diagnosis server and a historical knowledge base to monitor the health status of the engine in real time, so that the fault diagnosis efficiency is improved by more than 50%. BRIEF DESCRIPTION OF DRAWINGS

[0014] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the drawings needed to be used in the embodiments or prior art description will be briefly introduced. Obviously, the drawings in the following description are only some embodiments of the present application, and other drawings can be obtained by those skilled in the art without creative labor.

[0015] Figure 1 It is the system overall architecture schematic diagram in embodiment 1; Figure 2 It is the diagnosis method flow chart in embodiment 1; Figure 3 It is the diagnosis matching flow chart in embodiment 1; Figure 4 It is the knowledge base self-learning update flow chart in embodiment 2. DETAILED DESCRIPTION

[0016] The technical solutions in the embodiments of the present application will be described clearly and completely below with reference to the drawings in the embodiments of the present application. Obviously, the described embodiments are only some embodiments of the present application, not all. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative labor are within the scope of protection of the present application.

[0017] Embodiment 1 Please refer to Figures 1-3 As shown in the figure, an intelligent diagnosis system for an aero-engine includes an engine and a multi-physical field sensor network installed on the engine, a real-time feature extraction module deployed in an edge computing node, a central diagnosis server integrated with a machine learning engine, and a historical knowledge base storing structured fault cases and health management.

[0018] Multi-physical field sensor network: deployed in key positions such as engine rotor, turbine blade, lubrication system, air inlet and exhaust passage, to collect data such as vibration, oil pressure / temperature, air inlet pressure / temperature, exhaust gas temperature (EGT), and air path pressure ratio. The core function is to provide high-fidelity raw data for the system to support early identification of complex faults (such as judging lubrication system blockage through vibration frequency domain characteristics + oil pressure gradient).

[0019] Engine: the engine being tested.

[0020] Edge computing unit: deploy lightweight analysis algorithms: Envelope spectrum analysis: extract bearing fault characteristic frequency (such as BPFO / BPFI); Resonance demodulation technology: amplify early weak fault signals (SNR improvement ≥20dB); Data compression: reduce bandwidth load by 95% while retaining features (original 10MB / s → transmission 2MB / s).

[0021] Central diagnostic server: run a three-layer processing architecture: Feature fusion layer: concatenate multi-sensor feature vectors into a 32-dimensional input matrix; Fault classification model: XGBoost-based ensemble learning algorithm (200 decision trees, depth = 8); Knowledge graph engine: build a fault-reason-measure association network using Neo4j.

[0022] Historical knowledge base: use SAEARP926 standard encoding (e.g. F1001 = surge), store triples: < vibration spectrum peak @ 800Hz, fuel regulating valve jam, replace valve core + clean oil circuit >; Support cosine similarity retrieval (reuse historical solutions when threshold > 0.85).

[0023] Human-computer interaction device: push hierarchical alarm strategy: Level1 (yellow): suggest next stage inspection; Level2 (red): immediately stop for repair (associated with maintenance manual chapter) The system can realize three core functions: 1. Real-time monitoring and fault diagnosis: high-frequency acquisition of engine operating data, rapid matching of fault patterns through edge-cloud collaboration, output of diagnosis results and maintenance solutions; 2. Closed-loop self-learning optimization: based on maintenance verification results, automatically update knowledge base and incrementally optimize diagnosis model to continuously improve diagnosis accuracy; 3. Health Management Support: Through comparative analysis of historical and real-time data, it provides data and model support for engine health status assessment and remaining service life prediction. Working principle: The sensor network collects engine operating data in real time → the edge computing unit performs data preprocessing → the central server calls the diagnostic algorithm to match fault characteristics → a solution is generated and the knowledge base is updated synchronously → the engineer obtains the diagnostic results through the terminal.

[0024] Real-time monitoring phase: The sensor network collects engine status data at a sampling rate of 1000Hz, and the edge computing unit extracts key features (such as vibration spectrum peaks and lubricating oil pressure gradients).

[0025] Fault diagnosis phase: The central diagnostic server inputs the feature vector into the pre-trained fault classification model and matches it with the fault mode library (such as surge, stall, fuel leakage and other 20 typical faults).

[0026] Solution generation: A solution based on knowledge graph-based association of historical data.

[0027] Knowledge base update: New fault cases automatically generate structured data (fault phenomenon-cause-measure triplet), triggering incremental training of the diagnostic model.

[0028] The key data collection list is shown in the table below. The entire diagnostic matching process is as follows: Figure 2 As shown.

[0029] Example 2 Please see Figure 4 As shown, a method for updating an intelligent diagnostic knowledge base for aero-engines includes the following steps; T1: Real-time acquisition of multi-source data; T2: Data preprocessing and standardization (data cleaning, formatting, anonymization); T3: Feature Extraction and Knowledge Mining (Fault Feature Extraction, Association Rule Mining); T4: New Knowledge Judgment T4.1: Confirm new knowledge: include it in the knowledge base to be reviewed (with added confidence level and source), formally integrate and release the version (update the production environment knowledge base); T4.2: Conflict or uncertainty: Initiate expert review process (human-machine collaborative assessment); T5: Application feedback and effect tracking (diagnostic results, maintenance work order verification).

[0030] Working principle, DataInputLayer: 1. Real-time running data stream: Sources: Engine sensors (temperature, pressure, speed, vibration, etc.), ECU (engine control unit) fault codes (DTC), controller timing data.

[0031] Features: Massive data volume, real-time processing, and numerical analysis. Key to detecting early-stage hidden faults and performance degradation trends.

[0032] 2. Repair Cases and Post-Incident Reports: Sources: Repair work orders, final fault reports, replacement parts records, and engineer's handwritten notes.

[0033] Features: Contains a clear "symptom-diagnosis-repair" causal chain, making it the most reliable source of "facts" in the knowledge base.

[0034] 3. Domain expert experience: Source: Rules, experience, and judgment logic of senior calibration engineers and after-sales engineers.

[0035] Format: Rules for manual data entry, confirmation or correction of system prompts, conclusions of internal company seminars.

[0036] 4. External knowledge and research data: Sources: Manufacturer's Technical Bulletin (TSB), Design FMEA (Failure Mode and Effects Analysis), academic papers, industry reports.

[0037] Features: It has forward-looking and theoretical depth, and can be used to supplement rare failure modes.

[0038] 5. Diagnostic system feedback data: Source: Historical diagnostic records, accuracy rate of diagnostic conclusions, and records of rejections or confirmations by repair technicians.

[0039] Features: It directly reflects the blind spots or errors in the current knowledge base and serves as a direct basis for optimization.

[0040] Core processing and learning layer: 1. Data preprocessing and standardization: Data cleaning: processing sensor outliers, missing values, and noisy data.

[0041] Format standardization: Converting data from different sources (such as text reports, digital signals, and fault codes) into a unified, knowledge-base-understandable format (e.g., ontology-based representation).

[0042] Information extraction: Utilize NLP (Natural Language Processing) technology to automatically extract entities (such as part names and fault symptoms) and relationships (such as "cause" and "accompany") from unstructured texts such as repair reports.

[0043] 2. Feature Extraction and Knowledge Mining: Fault feature extraction: Apply signal processing (such as FFT, wavelet transform) and feature engineering methods to time-series sensor data to extract key features related to the fault.

[0044] Association rule mining: Apply machine learning algorithms (such as Apriori, FP-Growth) to discover strong association rules such as "fault code A + vibration feature B => faulty part C" from a large amount of historical data.

[0045] Anomaly detection: Unsupervised learning (such as isolated forests and autoencoders) is used to discover undefined and novel anomaly patterns as candidates for potential new knowledge.

[0046] Model training and validation: Supervised learning (such as decision trees, XGBoost, neural networks) is used to train diagnostic models, and the decision paths learned can be transformed into new knowledge rules.

[0047] 3. New knowledge assessment and conflict detection: Novelty detection: Newly discovered patterns and rules are compared with the existing knowledge base for similarity. If the matching degree is lower than the threshold, it is judged as "potential new knowledge".

[0048] Conflict detection: Checks whether new knowledge contradicts existing knowledge (e.g., the same set of symptoms corresponds to two different conclusions about failure). Conflicts must be flagged and handled by subsequent processes.

[0049] Knowledge Management & Update Layer: 1. Hierarchical knowledge base structure: Core knowledge base (stable area): Fully validated, high-confidence knowledge. It is the main engine of the diagnostic system.

[0050] Knowledge base awaiting review (incubation area): This area stores newly discovered, low-confidence, or potentially conflicting knowledge. Testing and validation are conducted in this area.

[0051] Case Library (Raw Data Area): Stores raw, cleaned case data for backtracking and relearning.

[0052] 2. Confidence Management: Assign a confidence score to each piece of knowledge. The initial confidence score is based on the reliability of its source (e.g., 0.95 for expert rules and 0.7 for data mining rules) and the statistical support of the data.

[0053] The confidence level is dynamically updated based on its accuracy in real-world diagnoses. It increases for each correct answer and decreases for each incorrect answer. Knowledge below a certain threshold is automatically downgraded or archived.

[0054] 3. Review and decision-making mechanism: Automatic updates: Knowledge with high confidence, no conflicts, and originating from authoritative sources (such as the manufacturer TSB) can be set to be automatically approved and incorporated into the core library.

[0055] Human-in-the-loop expert intervention: For conflicting knowledge, low-confidence knowledge, or knowledge with potentially significant impact, it must be pushed to the domain expert interface for final adjudication, correction, or confirmation. This is a crucial step in ensuring the reliability of the knowledge base.

[0056] 4. Version control and rollback: Every update to the knowledge base should have a version number and an update log, just like software.

[0057] Record the content, time, and reason for each modification (based on which case or algorithm). If new knowledge causes a decrease in diagnostic effectiveness, a quick rollback to the previous stable version should be possible.

[0058] Closed-loop feedback and optimization layer: 1. Effect tracking: After the knowledge is updated, the system actively tracks the verification results of the diagnostic suggestions based on the new knowledge in actual maintenance (confirmed through maintenance work orders).

[0059] Reinforcement Learning: Diagnostic results and repair verifications are used as reward signals to feed back into the learning algorithm, enabling it to continuously optimize knowledge extraction and diagnostic strategies. Knowledge Decay and Elimination: Knowledge that has not been used for a long time, or that is specific to older models and has decreased confidence, is automatically marked as "to be eliminated" and moved to the archive after confirmation, maintaining the simplicity and efficiency of the knowledge base. Update Trigger Conditions: When engineers confirm that the diagnostic results are valid and represent a new fault mode (knowledge base similarity < 0.7).

[0060] Structured storage process: ① Automatically generate triples: { "phenomenon": "Vibrational energy @ 2kHz > 0.5g² / Hz", "cause": "fatigue cracks in high-pressure turbine blades", "action": "Blade penetration test + replacement (based on MMEL78-21-03)" } ②Incremental training model: #Online Incremental Learning (Retaining Historical Weights) model.partial_fit(new_data,new_label,classes=20) ③ Update knowledge graph nodes: MERGE(f:Fault{code:"F1020"}) CREATE(c:Cause{name:"Blade fatigue crack"}) CREATE(a:Action{procedure:"MMEL78-21-03"}) CREATE(f)-[:CAUSED_BY]->(c)-[:SOLVED_BY]->(a).

[0061] In the description of this specification, references to terms such as "an embodiment," "example," "specific example," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of the invention. In this specification, illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0062] The foregoing has shown and described the basic principles, main features, and advantages of the present invention. Those skilled in the art should understand that the present invention is not limited to the above embodiments. The embodiments and descriptions in the specification are merely illustrative of the principles of the invention. Various changes and modifications can be made to the invention without departing from its spirit and scope, and all such changes and modifications fall within the scope of the claimed invention.

Claims

1. An intelligent diagnostic system for an aeroengine, characterized in that: The system comprises an engine and a multi-physical field sensor network installed on the engine, a real-time feature extraction module deployed on an edge computing node, a central diagnostic server integrated with a machine learning engine, and a historical knowledge base storing structured fault cases and health management; The multi-physical field sensor network comprises deployed engine rotors, turbine blades, lubrication systems, and intake and exhaust passages, responsible for collecting data such as vibration, oil pressure / temperature, intake pressure / temperature, exhaust gas temperature (EGT), and gas path pressure ratio.

2. The intelligent diagnostic system for aero-engines according to claim 1, characterized in that: The real-time feature extraction module includes an edge computing unit, envelope spectrum analysis, resonance demodulation technology, and data compression.

3. The intelligent diagnostic system for a gas turbine engine of claim 1, wherein: The central diagnostic server runs a three-layer processing architecture: Feature fusion layer: concatenating multi-sensor feature vectors into a 32-dimensional input matrix; Fault classification model: XGBoost-based ensemble learning algorithm (200 decision trees, depth = 8); Knowledge graph engine: building a fault-cause-measure association network using Neo4j.

4. The intelligent diagnostic system for a gas turbine engine of claim 1, wherein: The historical knowledge base uses SAEARP926 standard encoding (e.g. F1001 = surge), including storing triples: vibration spectrum peak @ 800 Hz, fuel regulating valve jamming, and replacing valve core + cleaning oil circuit, and supporting cosine similarity retrieval, case reuse mechanism based on similarity retrieval, and engine health real-time data storage function.

5. The intelligent diagnostic system for a gas turbine engine of claim 1, wherein: It also includes human-computer interaction equipment, which adopts a push hierarchical alarm strategy, Level 1 (yellow): suggests next stage inspection; Level 2 (red): immediate shutdown for repair (associated with repair manual chapter).

6. An intelligent diagnostic method for an aeroengine, characterized in that, The method is applicable to the intelligent diagnosis system of an aero-engine as claimed in any one of claims 1-5, and the diagnosis method comprises the following steps: S1: real-time acquisition of engine operating condition data and extraction of time-frequency domain features; S2: matching of pre-set fault modes through a fault classification model; S3: calling of a knowledge graph to generate a solution and pushing to a terminal; S4: structured storage of a new fault case to a knowledge base and optimization of a model.

7. The intelligent diagnostic method for aero-engines according to claim 6, characterized in that: The matching in step S2 comprises the following processes: a: feature vector standardization: inputting a 32-dimensional feature vector uploaded by an edge computing unit, using Z-score normalization (based on historical training set μ, σ) to eliminate dimensional differences, and outputting a standardized feature vector with a unified numerical range to adapt to the input requirements of subsequent models; b: fault type determination: high confidence confirmation: if the Top1 fault probability output by the XGBoost model is greater than a pre-set threshold (e.g. 0.85), the fault type is directly confirmed; low confidence voting: if the probability is less than or equal to the threshold, backup models such as random forest and lightweight neural network are called, and the final fault type is determined according to the "most frequent occurrence + highest probability average" rule; c: solution generation: based on the confirmed fault code (complying with SAEARP926 standard), retrieving "fault-cause-measure" associated data through a Neo4j knowledge graph engine, preferentially reusing historical effective solutions with a similarity greater than 0.85, and outputting a structured solution containing fault causes, repair steps, and reference manual chapters; d: Result push and feedback: push graded alarm (Level 1 yellow suggestion check, Level 2 red immediate shutdown) and solution to human-computer interaction equipment according to fault severity; Collect engineer maintenance verification results (diagnosis correctness, solution effectiveness), feedback to historical knowledge base, trigger closed-loop self-learning.

8. An intelligent diagnostic knowledge base updating method for an aeroengine, characterized in that, The method is suitable for the intelligent diagnosis system or the diagnosis method of any one of claims 1-7, and the knowledge base updating method comprises the following steps: T1: Real-time collection of multi-source data; T2: Data preprocessing and standardization (data cleaning, formatting, anonymization); T3: Feature extraction and knowledge mining (fault feature extraction, association rule mining); T4: New knowledge judgment: T4.1: Confirm new knowledge: include into the knowledge base to be audited (additional confidence and source), formally integrate and release version (update the production environment knowledge base); T4.2: Conflict or uncertainty: start expert audit process (human-computer collaborative research and judgment); T5: Application feedback and effect tracking (diagnosis result, maintenance work order verification).

9. The method of claim 8, wherein: The new knowledge judgment of step T4 includes novelty detection, and the newly mined patterns, rules and existing knowledge base are compared for similarity. If the matching degree is lower than the threshold, it is determined as "potential new knowledge", and the conflict or uncertainty includes logical contradiction between the new knowledge and the existing knowledge.

Images