Systems and Methods for Diagnosing Gas Turbine Engine Faults
专利汇可以提供Systems and Methods for Diagnosing Gas Turbine Engine Faults专利检索，专利查询，专利分析的服务。并且Systems and methods for diagnosing gas turbine engine faults are provided. In this regard, a representative method includes: dynamically assessing detected symptoms based, at least in part, on failure rates of components of the gas turbine engine as functions of usage of the components such that suspected faults are identified.，下面是Systems and Methods for Diagnosing Gas Turbine Engine Faults专利的具体信息内容。
The U.S. Government may have an interest in the subject matter of this disclosure as provided for by the terms of contract number N00019-02-C-3003 awarded by the United States Navy.
1. Technical Field
The disclosure generally relates to fault diagnosis of gas turbine engines.
2. Description of the Related Art
Engine diagnostic systems perform fault isolation functions that oftentimes involve ranking of probable faults. Such a fault ranking can be used to drive troubleshooting and maintenance procedures. Thus, the higher the true fault is ranked, the sooner the true fault typically is confirmed and corrected.
Systems and methods for diagnosing gas turbine engine faults are provided. In this regard, a representative embodiment of a method comprises: receiving a fault signal from an engine; determining the dynamic failure rate; and correlating the fault signal to the dynamic failure rate to identify a range of suspected faults.
Another exemplary embodiment of a method for diagnosing gas turbine engine faults comprises: dynamically assessing detected symptoms based, at least in part, on failure rates of components of the gas turbine engine as functions of usage of the components such that suspected faults are identified.
An exemplary embodiment of a gas turbine engine system comprises: an analysis system operative to receive information corresponding to a detected fault symptom of a gas turbine engine, receive information corresponding to dynamic failure rates of components of the gas turbine engine, and identify suspected faults of the gas turbine engine by correlating the information corresponding to the dynamic failure rates with the information corresponding to a detected symptom.
Other systems, methods, features and/or advantages of this disclosure will be or may become apparent to one with skill in the art upon examination of the following drawings and detailed description. It is intended that all such additional systems, methods, features and/or advantages be included within this description and be within the scope of the present disclosure.
Many aspects of the disclosure can be better understood with reference to the following drawings. The components in the drawings are not necessarily to scale. Moreover, in the drawings, like reference numerals designate corresponding parts throughout the several views.
Systems and methods for diagnosing gas turbine engine faults are provided, several exemplary embodiments of which will be described. In this regard, diagnosing of faults involves fault isolation, in which a group of suspected faults (known as an ambiguity group) is identified. Various techniques can be used to differentiate among the suspected faults of an ambiguity group, such as by ranking the suspected faults based on the relative probabilities of occurrence. Notably, failure rates of components implicated by the suspected faults are analyzed as functions of usage of the components. This is in contrast to conventional techniques that may consider a component failure rate to be constant throughout the life of a component. Notably, components can exhibit failure distributions that vary relatively significantly over time, such as failure distributions that are bell-shaped, with peak failures tending to occur at particular usage measurement units (e.g., a given number of flight hours). Other components may exhibit basin-shaped failure distributions with relatively high failure rates at both low and high usage times.
Reference now made to
Engine 100 also includes a diagnostic system 110 that includes a monitoring system 112 and an analysis system 120. Monitoring system 112 is depicted as including detectors 114, 116 and 118 positioned at locations A, B and C, respectively. The detectors monitor various parameters of the engine and provide information corresponding to those parameters to the analysis system. Various types of detectors can be used to monitor a variety of parameters such as vibrations, pressures and temperatures, for example. Parameters failing to meet predetermined criteria can be considered symptoms of a suspected fault. Notably, other types, numbers and positions of detectors can be used in other embodiments.
The analysis system 120 dynamically assesses detected symptoms based, at least in part, on failure rates of components of the gas turbine engine as functions of usage of the components. This enables the analysis system to identify and potentially rank the suspected faults. In some embodiments, depending upon the severity of a suspected fault, for example, a notification can be provided to the cockpit of an aircraft to which the gas turbine engine is mounted for informing the aircrew of the suspected condition. Additionally or alternatively, information can be provided to ground personnel, such as via a wired or wireless interface. In the case of wireless transmission, some embodiments could transmit information corresponding to the suspected faults prior to engine shutdown, such as during flight.
As shown in
Component failure rate system 158 provides component failure rate information (fi) to the analysis system. In some embodiments, the component failure rate information is provided in the form of a failure rate curve that plots failure of a component of interest against usage time. Notably, a designated engine component can have more than one set of failure rate information associated therewith. By way of example, in some embodiments, failure rate information can be stored with respect to OEM components and repaired components, with an appropriate set of the information being accessed depending upon the nature of the component of interest.
Using the information available to the analysis system, the analysis system outputs suspected faults that are ranked. Notably, the ranking is based, at least in part, on the dynamic fault rates (i.e., the fault rate information correlated with the actual usage time of the components).
The following outlines an exemplary methodology for diagnosing suspected engine faults. In this regard, assume that N types of engine faults (F1, F2, . . . , FN) are being monitored. The failure rate fi associated with fault Fi is the occurrence frequency of that fault within a given amount of time (e.g., one million flight hours). Let S1, S2, . . . , SM be symptoms that can be detected by the diagnostic system. Then, the task of fault isolation in the diagnostic system is to provide a ranked component list that is associated with a subset of faults F1, F2, . . . , FN, if a subset S of symptoms S2, . . . , SM is detected.
Providing such ranked fault list can be based on the magnitudes of conditional probabilities of the faults given a subset of detected symptoms. Using the Bayesian formula, the rank for the ith fault is
Rank(i)=p(Fi|S)
=p(Fi)×p(S|Fi)/p(S) (1)
where:
- S is the subset of symptoms detected;
- p(Fi|S) is the conditional probability that the ith fault Fi occurs given S is detected;
- p(Fi) is the probability of fault Fi;
- p(S|Fi) is the conditional probability that S would be detected if the fault Fi occurs; and
- p(S) is the probability that S would be detected.
The index i typically involves only those faults that are related to the detected symptoms. The indexes of these faults can be denoted as I.
In Equation 1, p(S) is a common denominator, independent of index i, and can be calculated as
p(S|Fi) can be calculated from a Fault-Symptom model, usually a Bayesian Network model. Finally, p(Fi) can be calculated using failure rates of involved faults, i.e.
As mentioned before, in this example failure rate is the occurrence frequency of a fault within one million flight hours. Such a failure rate can be estimated from historical maintenance records of, may be, multiple engine types. Unfortunately, a failure rate estimated in this manner may not reflect true failure rates of components associated with the specific engine type that the diagnostic system is monitoring. Moreover, such a failure rate may be assumed to be constant with respect to the life of a component. For many engine components, such an assumption also may not be true.
In this regard, the failure rate curve for each implicated component can be used to calculate failure probability in Equation 2 above. Thus, the failure rate is the failure likelihood as a function of component life usage. Stated otherwise, the failure rate curve (or failure distribution curve) for each possible fault (failure mode) is probability distribution function with respect to life usage index for each component and is substituted into Equation 2. Such a failure rate curve for the ith fault is denoted as fi(ui), where ui is the life usage index for the ith component fault generated by a component-usage tracking system at the time the symptoms S are detected. Then, the Equation 2 that calculates fault probability becomes
Using Equation (3), the probability of fault can be calculated more accurately, and hence the fault ranking generated by Equation 1 can be improved. That is, the likelihood of a true fault being ranked higher relative to other fault rankings increases. Furthermore, in cases in which fi(ui) equals zero at a given component usage for some faults i, the ranked fault list will be shorter, resulting in a reduced ambiguity group size. The benefit of the concept explained above can be demonstrated through following abstract example.
Consider a scenario that a gas turbine engine has operated for 900 hours since installed to aircraft, and all components have the same life usage (900 hours). A subset of symptoms S is then detected, indicating a functional failure occurs. Assume two faults, F1 and F2, are the only possible root causes equally likely responsible for the detected S, meaning p(S|F1)=p(S|F2)≠0. Furthermore, assume the failure rate for the fault F1 is 5 occurrences per million fight hours, and the failure rate for the fault F2 is 3 occurrences per million fight hours. Assume also the failure rate distributions are available, given in Table 1:
The task for the diagnostic system is to identify the real fault by properly ranking the ambiguity group, {F1, F2} in this case, such that the real fault is ranked higher.
With a conventional method, where the failure rate fi is assumed being constant, the fault probabilities and the ranks for both faults are calculated using Equation (2) as:
Thus, the rank for F1 is higher than that for F2, i.e. Rank (1)≧Rank (2) since p(S|F1)=p(S|F2), and p(S) are common denominators to both ranks.
In some embodiments of a diagnostic system, the fault probabilities and the ranks for both faults can be calculated using Equation (3) as
Thus, the rank for F1 is lower than that for F2, i.e. Rank (1)≦Rank (2).
As shown in the failure rate table, it can be seen that even though the total failure occurrences for F1 is higher than that for F2 for one million fight hours, for the given scenario the fault 2 is twice more likely occurred than the fault 1 at usage life 900 hours. Hence, ranking the fault 2 higher than fault 1 twice more likely provides correct ranking than the conventional method. It should be emphasized that the intent is not to provide correct ranking every single time, but rather to increase the likelihood of correct ranking.
Various functionalities, such as that described above in the flowcharts can be implemented in hardware and/or software. In this regard, a computing device can be used to implement various functionality, such as that depicted in
In terms of hardware architecture, such a computing device can include a processor, memory, and one or more input and/or output (I/O) device interface(s) that are communicatively coupled via a local interface. The local interface can include, for example but not limited to, one or more buses and/or other wired or wireless connections. The local interface may have additional elements, which are omitted for simplicity, such as controllers, buffers (caches), drivers, repeaters, and receivers to enable communications. Further, the local interface may include address, control, and/or data connections to enable appropriate communications among the aforementioned components.
The processor may be a hardware device for executing software, particularly software stored in memory. The processor can be a custom made or commercially available processor, a central processing unit (CPU), an auxiliary processor among several processors associated with the computing device, a semiconductor based microprocessor (in the form of a microchip or chip set), a microprocessor, or generally any device for executing software instructions.
The memory can include any one or combination of volatile memory elements (e.g., random access memory (RAM, such as DRAM, SRAM, SDRAM, VRAM, etc.)) and/or nonvolatile memory elements (e.g., ROM, hard drive, tape, CD-ROM, etc.). Moreover, the memory may incorporate electronic, magnetic, optical, and/or other types of storage media. Note that the memory can also have a distributed architecture, where various components are situated remotely from one another, but can be accessed by the processor.
The software in the memory may include one or more separate programs, each of which includes an ordered listing of executable instructions for implementing logical functions. A system component embodied as software may also be construed as a source program, executable program (object code), script, or any other entity comprising a set of instructions to be performed. When constructed as a source program, the program is translated via a compiler, assembler, interpreter, or the like, which may or may not be included within the memory.
The Input/Output devices that may be coupled to system I/O Interface(s) may include input devices, for example but not limited to, a keyboard, mouse, scanner, microphone, camera, proximity device, etc. Further, the Input/Output devices may also include output devices, for example but not limited to, a printer, display, etc. Finally, the Input/Output devices may further include devices that communicate both as inputs and outputs, for instance but not limited to, a modulator/demodulator (modem; for accessing another device, system, or network), a radio frequency (RF) or other transceiver, a telephonic interface, a bridge, a router, etc.
When the computing device is in operation, the processor can be configured to execute software stored within the memory, to communicate data to and from the memory, and to generally control operations of the computing device pursuant to the software. Software in memory, in whole or in part, is read by the processor, perhaps buffered within the processor, and then executed.
One should note that the flowcharts included herein show the architecture, functionality, and operation of a possible implementation of software. In this regard, each block can be interpreted to represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that in some alternative implementations, the functions noted in the blocks may occur out of the order and/or not at all. For example, two blocks shown in succession may in fact be executed substantially concurrently or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved.
One should note that any of the functionality described herein can be embodied in any computer-readable medium for use by or in connection with an instruction execution system, apparatus, or device, such as a computer-based system, processor-containing system, or other system that can fetch the instructions from the instruction execution system, apparatus, or device and execute the instructions. In the context of this document, a “computer-readable medium” contains, stores, communicates, propagates and/or transports the program for use by or in connection with the instruction execution system, apparatus, or device. The computer readable medium can be, for example but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device. More specific examples (a nonexhaustive list) of a computer-readable medium include a portable computer diskette (magnetic), a random access memory (RAM) (electronic), a read-only memory (ROM) (electronic), an erasable programmable read-only memory (EPROM or Flash memory) (electronic), and a portable compact disc read-only memory (CDROM) (optical).
It should be emphasized that the above-described embodiments are merely possible examples of implementations set forth for a clear understanding of the principles of this disclosure. Many variations and modifications may be made to the above-described embodiments without departing substantially from the spirit and principles of the disclosure. All such modifications and variations are intended to be included herein within the scope of this disclosure and protected by the accompanying claims.
| 标题 | 发布/更新时间 | 阅读量 |
|---|---|---|
| 用于涡轮发动机的保养管 | 2020-05-08 | 843 |
| 具有增材制造整流罩的增材制造管道式换热器系统 | 2020-05-08 | 383 |
| 具有波纹管的放气阀 | 2020-05-08 | 927 |
| 基于飞参数据辨识的航空燃气涡轮发动机建模方法 | 2020-05-11 | 390 |
| 用于检测高涡轮温度操作的方法和系统 | 2020-05-12 | 669 |
| 用于在翼修理的燃气涡轮机就地可膨胀囊袋 | 2020-05-08 | 869 |
| 用于先进膜冷却的具有小复杂特征的CMC制品 | 2020-05-08 | 222 |
| 回流燃烧室与涡轮导向器的连接结构及燃气涡轮发动机 | 2020-05-08 | 147 |
| 一种三体船 | 2020-05-08 | 1811 |
| 用于为发动机启动设定加速度计划的方法与系统 | 2020-05-11 | 119 |
高效检索全球专利专利汇是专利免费检索,专利查询,专利分析-国家发明专利查询检索分析平台，是提供专利分析，专利查询，专利检索等数据服务功能的知识产权数据服务商。
我们的产品包含105个国家的1.26亿组数据，免费查、免费专利分析。
专利汇分析报告产品可以对行业情报数据进行梳理分析，涉及维度包括行业专利基本状况分析、地域分析、技术分析、发明人分析、申请人分析、专利权人分析、失效分析、核心专利分析、法律分析、研发重点分析、企业专利处境分析、技术处境分析、专利寿命分析、企业定位分析、引证分析等超过60个分析角度，系统通过AI智能系统对图表进行解读，只需1分钟，一键生成行业专利分析报告。
