Architecture For Turbine System Diagnosis Based On Sensor Data

Abstract

A method of diagnosing a turbine system including: receiving sensor data of a first component of the turbine system (303a); identifying a mode of the first component (307a); inputting the sensor data and the mode of the first component into a first model-based diagnostic engine (311a) and a data-driven diagnostic engine (313a) to generate a first component diagnosis (315a); receiving sensor data of a second component of the turbine system (303x); identifying a mode of the second component (307x); inputting the sensor data and the mode of the second component into a second model-based diagnostic engine (311x) and the data-driven diagnostic engine (313x) to generate a second component diagnosis (315x); generating a component abstraction for the first component diagnosis and the second component diagnosis (317); and inputting the component abstraction to a system model-based diagnostic engine (319) to generate a first diagnosis of the turbine system (321).

Description

BACKGROUND OF THE INVENTION

1. Technical Field

The present invention relates to sensor-based diagnosis, and more particularly, to a system of diagnosing turbine systems based on sensor data.

2. Discussion of the Related Art

A turbine is a rotary mechanical device that extracts energy from a fluid flow and converts it to useful work. The fluid may be liquid or gas. A turbine is a turbomachine with at least one moving part called a rotor assembly, which is a shaft or drum with blades attached. Moving fluid acts on the blades so that they move and impart rotational energy to the rotor.

Turbine examples include steam turbines, gas turbines, transonic turbines, contra-rotating turbines, statorless turbines, ceramic turbines, shrouded turbines, shroudless turbines, bladeless turbines, water turbines and wind turbines.

As an example, a wind turbine converts kinetic energy from the wind, also called wind energy, into mechanical energy in a process known as wind power. Large grid-connected arrays of wind turbines are becoming an increasingly important source of wind power-produced commercial electricity.

FIG. 1 is an example of a wind turbine system 100. The wind turbine system 100 may include blades 1, a rotor 2, a blade pitch 3, a brake 4, a low-speed shaft 5, a gear box 6, a generator 7, a controller 8, an anemometer 9, a wind vane 10, a nacelle 11, a high-speed shaft 12, a yaw drive 13, a yaw motor 14 and a tower 15.

FIG. 2 is an example of turbine system diagnosis. Although FIG. 2 shows a wind turbine system 210 as the system under diagnosis, the illustrated diagnosis approach is applicable to most turbine systems.

As shown in FIG. 2, a monitor and diagnostic system 220 may receive a system model 230 of the wind turbine system 210 and sensor data 240 from sensors 250 of the wind turbine system 210. The system model 230 of the wind turbine system 210 may include models of the system's components, a description of how the components are connected, intended/unintended behaviors of the system and known failures of the system. Mode data may also be provided from the wind turbine system 210. The sensors 250 may be directly coupled with the system's components or strategically placed. The monitor and diagnosis system 220 may output a diagnosis 260 for visual display 270.

A diagnosis system may be model-based or data driven. A model-based system relies on a model of a system, how system components are connected, how they are intended to function, etc. A data-driven system may make a diagnosis based solely on sensor data.

System models include dependency models such as Qualtech Systems' Testability, Engineering, and Maintenance System (TEAMS), eXpress by DSI International and “G²: A Graph Processing System for Diagnosing Distributed Systems,” Gou et al., 2011 (G2), logical models such as Propositional Satisfiability (SAT), Communicating Sequential Processes (CSP), Satisfiability Modulo Theories (SMT), Prolog, Description Logic (DL) and Answer Set Programming (ASP), and hybrid models such as Hybrid Diagnosis Engine (HyDE).

System mode can be detected by using expert systems such as G2 and Spacecraft Health Inference Engine (SHINE), data-driven approaches, logical models such as SAT, CSP, Prolog, DL and ASP, and hybrid models such as HyDE.

SUMMARY OF THE INVENTION

According to an exemplary embodiment of the present invention, a method of diagnosing a turbine system comprises: receiving sensor data of a first component of the turbine system; identifying a mode of the first component; inputting the sensor data and the mode of the first component into a first model-based diagnostic engine and a data-driven diagnostic engine to generate a first component diagnosis; receiving sensor data of a second component of the turbine system; identifying a mode of the second component; inputting the sensor data and the mode of the second component into a second model-based diagnostic engine and the data-driven diagnostic engine to generate a second component diagnosis; generating a component abstraction for the first component diagnosis and the second component diagnosis; and inputting the component abstraction to a system model-based diagnostic engine to generate a first diagnosis of the turbine system.

The sensor data of the first component is provided from one or more sensors. The first component diagnosis is generated by integrating results of the first model-based diagnostic engine and the data-driven model.

The system model-based diagnostic engine uses non-monotonic reasoning.

The system model-based diagnostic engine include models expressed with Satisfiability Modulo Theories.

The system model-based diagnostic engine handles discrete and continuous behaviors.

The method further comprises: receiving sensor data of a third component of the turbine system; identifying a mode of the third component; inputting the sensor data and the mode of the third component into a third model-based diagnostic engine and the data-driven diagnostic engine to generate a third component diagnosis; generating a component abstraction for the third component diagnosis; and inputting the component abstraction for the third component diagnosis to the system model-based diagnostic engine to generate a second diagnosis of the turbine system.

The first and second components are diagnosed in parallel.

According to an exemplary embodiment of the present invention, a system for diagnosing a turbine system comprises: a memory device for storing a program; a processor in communication with the memory device, the processor operative with the program to: receive sensor data of a first component of the turbine system; identify a mode of the first component; input the sensor data and the mode of the first component into a first model-based diagnostic engine and a data-driven diagnostic engine to generate a first component diagnosis; receive sensor data of a second component of the turbine system; identify a mode of the second component; input the sensor data and the mode of the second component into a second model-based diagnostic engine and the data-driven diagnostic engine to generate a second component diagnosis; generate a component abstraction for the first component diagnosis and the second component diagnosis; and input the component abstraction to a system model-based diagnostic engine to generate a first diagnosis of the turbine system.

The sensor data of the first component is provided from one or more sensors.

The first component diagnosis is generated by integrating results of the first model-based diagnostic engine and the data-driven model.

The system model-based diagnostic engine uses non-monotonic reasoning.

The system model-based diagnostic engine include models expressed with Satisfiability Modulo Theories.

The system model-based diagnostic engine handles discrete and continuous behaviors.

The processor is further operative with the program to: receive sensor data of a third component of the turbine system; identify a mode of the third component; input the sensor data and the mode of the third component into a third model-based diagnostic engine and the data-driven diagnostic engine to generate a third component diagnosis; generate a component abstraction for the third component diagnosis; and input the component abstraction for the third component diagnosis to the system model-based diagnostic engine to generate a second diagnosis of the turbine system.

The first and second components are diagnosed in parallel.

According to an exemplary embodiment of the present invention, a computer program product for diagnosing a turbine system comprises: a non-transitory computer readable storage medium having computer readable program code embodied therewith, the computer readable program code comprising: computer readable program code configured to perform the steps of: receiving sensor data of a first component of the turbine system; identifying a mode of the first component; inputting the sensor data and the mode of the first component into a first model-based diagnostic engine and a data-driven diagnostic engine to generate a first component diagnosis; receiving sensor data of a second component of the turbine system; identifying a mode of the second component; inputting the sensor data and the mode of the second component into a second model-based diagnostic engine and the data-driven diagnostic engine to generate a second component diagnosis; generating a component abstraction for the first component diagnosis and the second component diagnosis; and inputting the component abstraction to a system model-based diagnostic engine to generate a first diagnosis of the turbine system.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is an example of a wind turbine system;

FIG. 2 is an example of turbine system diagnosis;

FIG. 3 is a turbine system diagnosis architecture according to an exemplary embodiment of the present invention;

FIG. 4 is a schematic diagram illustrating the diagnosis approach of FIG. 3; and

FIG. 5 is a computer system in which an exemplary embodiment of the present invention may be implemented.

DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTS

The present invention is directed to a turbine system diagnosis architecture. The turbine system diagnosis architecture of the present invention is applicable to all turbine systems including, but not limited to, steam turbines, gas turbines, transonic turbines, contra-rotating turbines, statorless turbines, ceramic turbines, shrouded turbines, shroudless turbines, bladeless turbines, water turbines and wind turbines.

FIG. 3 is a turbine system diagnosis architecture according to an exemplary embodiment of the present invention.

As shown in FIG. 3, sensor data 303a is received at a diagnostic system and validated 305a. The sensor data 303a is provided from a sensor connected with a component (e.g., a first component) of a plurality of components of a turbine system. For example, the sensor could be a command sensor, a measurement sensor for monitoring temperature, pressure flow, etc. The sensor data may include numeric values at various time intervals. The sensor data 303a is validated so that the data they output can be trusted. For example, validation ensures that things like vibration or weather do not influence sensor values that are later to be explained by the diagnosis system.

The mode of the first component may be identified 307a. The component mode may take into account different regimes of functioning of the component or the overall system: for example before reaching the working regime (aka “online”), a turbine goes through a “start-up” during which its speed reaches the cruising speed at which power output is optimal. The mode of functioning influences the diagnostic engine as the way components function in each mode is different. Incoming validated sensor data 303a may be constantly monitored 309a.

The validated sensor data 303a and its corresponding mode 307a, if any, are provided to a model-based diagnostic engine 311a and a data-driven diagnostic engine 313a. The model-based diagnostic engine 311a is a single component model and is specific to the first component. The model-based diagnostic engine 311a may be obtained from a domain expert and formalized as a set of logical rules describing how the system should perform, the set of constraints it should obey, etc. For example, one can say about a pressure valve that if it is open, then the pressure downstream from it should increase. Any other reading would mean a malfunction. The model-based engine can identify that a fault occurred (like in the previous example) and can diagnose the fault by identifying the component(s) that could have produced it. Some systems may even provide possible diagnostic steps that would remedy the situation.

The data-driven engine 313a may be learned from sensor data annotated as either faulty or normal and may produce as output such faulty or normal findings for unseen sensor data.

In parallel with the process performed on the sensor data 303a, sensor data 303x is received at the diagnostic system and validated 305x. The sensor data 303x is provided from a sensor connected with another component (e.g., a second component) of the plurality of components of the turbine system. The mode of the second component may be identified 307x and incoming validated sensor data 303x may be constantly monitored 309x.

The validated sensor data 303x and its corresponding mode 307x, if any, are provided to a model-based diagnostic engine 311x and a data-driven diagnostic engine 313x. The model-based diagnostic engine 311x is specific to the second component. The data-driven diagnostic 313x engine is tuned to the second component.

An output 315a of the model-based diagnostic engine 311a and the data-driven diagnostic engine 313a is provided to a component abstraction module 317. Similarly, an output 315x of the model-based diagnostic engine 311x and the data-driven diagnostic engine 313x is provided to the component abstraction module 315.

Although the above description only discusses the two component outputs 315a and 315x being input to the component abstraction module 317, the number of component outputs received at the component abstraction module 317 is not limited thereto and can be much greater. Further, these outputs do not have to be received in parallel, but instead can be received at different times.

In response to the receipt of the component diagnosis 315a and 315x, the component abstraction module 317 aims to improve diagnostics by abstracting away from individual components and their behavior. One way to achieve this is to remove distinctions that are not important for the considered system. For example, two pipes connected to the input and output of a valve can be abstracted to just the valve.

The output of the component abstraction module 317 is provided to a model-based diagnostic engine 319 and a system diagnosis 321 output therefrom.

To help illustrate this diagnostic approach, a Water Tank Problem (WTP) will now be discussed. FIG. 4 is a schematic diagram illustrating the WTP. Here there are two tanks, a left tank 410 and a right tank 411. A single tap 412 is free to move between each tank to fill both tanks with water. Each tank has a hole at the bottom that loses water. The left tank 410 loses water at a rate of v1 while the right tank 411 loses water at a rate of v2. The tap 412 fills either tank at a rate w. For simplicity, it may be assumed that v1=v2=v and w>v. A command called “switch” may be used to move the tap to change tanks.

Sensor x1 is a Boolean sensor monitoring the state of the left tank 10 while sensor x2 is a Boolean sensor monitoring the state of the right tank 411. Sensors x1 and x2 register a ‘1’ when the water level in their respective tank increases and they register a ‘0’ when the water level in their respective tank decreases.

Now assuming at time 1 the value of x1 is ‘1’ and the value of x2 is ‘0’. This would indicate that the tap 412 is filling the left tank 410. Assuming the “switch” command is issued between time 1 and time 2, and at time 2, the values of x1 and x2 are still ‘1’ and ‘0’, respectively, the values of x1 and x2 are now considered to be abnormal as the system would have expected x1 to be at ‘0’ and x2 to be at ‘1’ after the switch. In this scenario, the tap 412 has become stuck over the left tank 410. However, as there is no sensor for the tap 412, this problem cannot be directly observed and thus a diagnosis is needed.

A model based engine employing non-monotonic reasoning may be used to examine the state of x1 and x2 together. The fact that x2 is decreasing and not increasing may indicate that the right tank 411 has failed, for example, due to a leak. However, when combined with the fact that x1 is increasing and not decreasing, it may be determined that it is the tap 412 that is malfunctioning. One example of a formalism that is capable of expressing such models is Satisfiability Modulo Theories (SMT). SMT is a decision problem for logical formulas with respect to combinations of background theories expressed in classical first-order logic. Advantages of using SMT include the ability to handle both discrete and continuous behaviors, for example.

As will be appreciated by one skilled in the art, aspects of the present invention may be embodied as a system, method or computer program product. Accordingly, aspects of the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a “circuit,” “module” or “system.” Furthermore, aspects of the present invention may take the form of a computer program product embodied in one or more computer readable medium(s) having computer readable program code embodied thereon.

Any combination of one or more computer readable medium(s) may be utilized. The computer readable medium may be a computer readable signal medium or a computer readable storage medium. A computer readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples (a non-exhaustive list) of the computer readable storage medium would include the following: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this document, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device.

A computer readable signal medium may include a propagated data signal with computer readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A computer readable signal medium may be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device.

Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.

Computer program code for carrying out operations for aspects of the present invention may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, Smalltalk, C++ or the like and conventional procedural programming languages, such as the “C” programming language or similar programming languages. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider).

Aspects of the present invention are described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.

These computer program instructions may also be stored in a computer readable medium that can direct a computer, other programmable data processing apparatus, or other devices to function in a particular manner, such that the instructions stored in the computer readable medium produce an article or manufacture including instructions which implement the function/act specified in the flowchart and/or block diagram block or blocks.

The computer program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other devices to cause a series of operational steps to be performed on the computer, other programmable apparatus or other devices to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide processes for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.

Referring now to FIG. 5, according to an exemplary embodiment of the present invention, a computer system 501 can comprise, inter alia, a central processing unit (CPU) 502, a memory 503 and an input/output (I/O) interface 504. The computer system 501 is generally coupled through the I/O interface 504 to a display 505 and various input devices 506 such as a mouse and keyboard. The support circuits can include circuits such as cache, power supplies, clock circuits, and a communications bus. The memory 503 can include RAM, ROM, disk drive, tape drive, etc., or a combination thereof. Exemplary embodiments of present invention may be implemented as a routine 507 stored in memory 503 (e.g., a non-transitory computer-readable storage medium) and executed by the CPU 502 to process the signal from a signal source 508. As such, the computer system 501 is a general-purpose computer system that becomes a specific purpose computer system when executing the routine 507 of the present invention.

The computer system 501 also includes an operating system and micro-instruction code. The various processes and functions described herein may either be part of the micro-instruction code or part of the application program (or a combination thereof) which is executed via the operating system. In addition, various other peripheral devices may be connected to the computer system 501 such as an additional data storage device and a printing device.

The flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagrams may 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 block may occur out of the order noted in the figures. 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. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention. As used herein, the singular forms “a,” “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises” and/or “comprising,” when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.

The corresponding structures, materials, acts, and equivalents of all means or step plus function elements in the claims below are intended to include any structure, material, or act for performing the function in combination with other claimed elements as specifically claimed. The description of the present invention has been presented for purposes of illustration and description, but is not intended to be exhaustive or limited to the invention in the form disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the invention. The embodiment was chosen and described to best explain the principles of the invention and the practical application, and to enable others of ordinary skill in the art to understand the invention for various embodiments with various modifications as are suited to the particular use contemplated.

Claims

1. A method of diagnosing a turbine system, comprising: receiving sensor data of a first component of the turbine system;identifying a mode of the first component;inputting the sensor data and the mode of the first component into a first model-based diagnostic engine and a data-driven diagnostic engine to generate a first component diagnosis;receiving sensor data of a second component of the turbine system;identifying a mode of the second component;inputting the sensor data and the mode of the second component into a second model-based diagnostic engine and the data-driven diagnostic engine to generate a second component diagnosis;generating a component abstraction for the first component diagnosis and the second component diagnosis; andinputting the component abstraction to a system model-based diagnostic engine to generate a first diagnosis of the turbine system.

2. The method of claim 1, wherein the sensor data of the first component is provided from one or more sensors.

3. The method of claim 1, wherein the first component diagnosis is generated by integrating results of the first model-based diagnostic engine and the data-driven model.

4. The method of claim 1, wherein the system model-based diagnostic engine uses non-monotonic reasoning.

5. The method of claim 4, wherein the system model-based diagnostic engine include models expressed with Satisfiability Modulo Theories.

6. The method of claim 5, wherein the system model-based diagnostic engine handles discrete and continuous behaviors.

7. The method of claim 1, further comprising: receiving sensor data of a third component of the turbine system;identifying a mode of the third component;inputting the sensor data and the mode of the third component into a third model-based diagnostic engine and the data-driven diagnostic engine to generate a third component diagnosis;generating a component abstraction for the third component diagnosis; andinputting the component abstraction for the third component diagnosis to the system model-based diagnostic engine to generate a second diagnosis of the turbine system.

8. The method of claim 1, wherein the first and second components are diagnosed in parallel.

9. A system for diagnosing a turbine system, comprising: a memory device for storing a program;a processor in communication with the memory device, the processor operative with the program to:receive sensor data of a first component of the turbine system;identify a mode of the first component;input the sensor data and the mode of the first component into a first model-based diagnostic engine and a data-driven diagnostic engine to generate a first component diagnosis;receive sensor data of a second component of the turbine system;identify a mode of the second component;input the sensor data and the mode of the second component into a second model-based diagnostic engine and the data-driven diagnostic engine to generate a second component diagnosis;generate a component abstraction for the first component diagnosis and the second component diagnosis; andinput the component abstraction to a system model-based diagnostic engine to generate a first diagnosis of the turbine system.

10. The system of claim 9, wherein the sensor data of the first component is provided from one or more sensors.

11. The system of claim 9, wherein the first component diagnosis is generated by integrating results of the first model-based diagnostic engine and the data-driven model.

12. The system of claim 9, wherein the system model-based diagnostic engine uses non-monotonic reasoning.

13. The system of claim 12, wherein the system model-based diagnostic engine include models expressed with Satisfiability Modulo Theories.

14. The system of claim 13, wherein the system model-based diagnostic engine handles discrete and continuous behaviors.

15. The system of claim 9, wherein the processor is further operative with the program to: receive sensor data of a third component of the turbine system;identify a mode of the third component;input the sensor data and the mode of the third component into a third model-based diagnostic engine and the data-driven diagnostic engine to generate a third component diagnosis;generate a component abstraction for the third component diagnosis; andinput the component abstraction for the third component diagnosis to the system model-based diagnostic engine to generate a second diagnosis of the turbine system.

16. The system of claim 9, wherein the first and second components are diagnosed in parallel.

17. A computer program product for diagnosing a turbine system, comprising: a non-transitory computer readable storage medium having computer readable program code embodied therewith, the computer readable program code comprising:computer readable program code configured to perform the steps of:receiving sensor data of a first component of the turbine system;identifying a mode of the first component;inputting the sensor data and the mode of the first component into a first model-based diagnostic engine and a data-driven diagnostic engine to generate a first component diagnosis;receiving sensor data of a second component of the turbine system;identifying a mode of the second component;inputting the sensor data and the mode of the second component into a second model-based diagnostic engine and the data-driven diagnostic engine to generate a second component diagnosis;generating a component abstraction for the first component diagnosis and the second component diagnosis; andinputting the component abstraction to a system model-based diagnostic engine to generate a first diagnosis of the turbine system.