US20060026209A1

US20060026209A1 - System and method for processing control data

Info

Publication number: US20060026209A1
Application number: US11/207,087
Authority: US
Inventors: Garth Burrill; Thomas Christiansen; Salvatore DellaVilla.; Kevin Dunn; Robert Steele; David Turpin
Original assignee: Individual
Current assignee: Individual
Priority date: 2002-09-05
Filing date: 2005-08-18
Publication date: 2006-02-02
Also published as: US7333918B2; US20040049480A1

Abstract

A data collection engine for collecting a stream of dynamic data from a plant, comprising: a first computer process for receiving the dynamic data and for saving the dynamic data as database records in a series of log files within a file folder; and a second computer process for reading the database records from the log files, and storing the database records in a database.

Description

This application is a divisional and claims priority of application Ser. No. 10/403,629, filed Mar. 31, 2003, currently pending, which claims priority from co-pending provisional application Ser. No. 60/408,428 filed on Sep. 5, 2002, entitled “ORAP LINK data monitoring, analysis and storage engine.”

BACKGROUND OF THE INVENTION

1. Technical Field
The present invention relates generally to processing control data, and more particularly relates to managing reliability data collected from an industrial plant.
2. Related Art
Like most large-scale industrial operations, modern power plants require a tremendous amount of scheduled maintenance to operate at peak efficiency. Typical maintenance involves inspecting turbine parts, analyzing inspection data, calculating expected lifespan of parts, and replacing and/or servicing parts. Given the costs involved in providing such services, effectively managing the maintenance processes can have a substantial impact on plant profitability.
One specific challenge with servicing power plants involves how to collect and utilize data necessary to make intelligent maintenance decisions, such as when parts should be replaced, etc. However, because of the number of parts and variables that exist for maintaining a complicated system such as a gas turbine, automation of the maintenance process is a complex problem. While systems exist for tracking parts and maintenance histories (i.e., static data), the life expectancy of each component is going to depend greatly on numerous operational characteristics that the component was subject to (e.g., hours of operation, starts, etc.). Therefore, tracking parts life requires measuring and tracking not only the parts themselves, but also the operational characteristics of hundreds or thousands of parts, which represents a significant challenge.
Power plants generate thousands of raw operational data points (i.e., dynamic data) each second including, e.g., temperature measurements, turbine speed, trips, hours of operation, fuel consumption, startup information, etc. The mere act of capturing and storing thousands of raw data points in a near real-time environment can require significant computing resources. This, combined with the need to provide analysis and storage tools to convert the data into some useful information creates significant data processing obstacles.
Accordingly, in order to provide an automated and comprehensive maintenance program, all reliability data including both dynamic data (operational information) and static data (part information and general maintenance records) must be carefully tracked and incorporated into any reliability analysis. Moreover, even if such comprehensive reliability data exists, such records may exist only in manual logs and/or in disparate electronic formats. Accordingly, numerous challenges exist with respect to effectively maintaining large-scale control operations, such as power plants. Without an automated system for more effectively managing reliability information, maintaining such plants will remain an inefficient process.

SUMMARY OF THE INVENTION

The present invention addresses the above-mentioned problems, as well as others by providing comprehensive data processing solutions for reliability data in plant environments such as power generation plants. In a first aspect, the invention provides a data collection engine for collecting a stream of dynamic data from a plant, comprising: a first computer process for receiving the dynamic data and for saving the dynamic data as database records in a series of log files within a file folder; and a second computer process for reading the database records from the log files, and storing the database records in a database.
In a second aspect, the invention provides a method for collecting a stream of dynamic plant data, comprising: using a first computer process to receive the dynamic plant data and to save the dynamic plant data as database records in a series of log files within a file folder; and using a second computer process to read the database records from the log files and store the database records in a database.
In a third aspect, the invention provides a system for utilizing reliability data from a plant to dynamically calculate an expended life for a selected part, comprising: a central database for storing service data for parts within the plant; a data collection engine for dynamically collecting operational data from the plant in a near real-time manner; and a lifetime calculation engine for implementing a lifetime calculation equation for the selected part, wherein the lifetime calculation equation utilizes the service data and the operational data to determine the expended life of the selected part.
In a fourth aspect, the invention provides a method of utilizing reliability data from a plant to dynamically calculate an expended life for a selected part, comprising: storing service data for plant parts; dynamically collecting operational data from the plant in a near real-time manner; and calculating the expended life of the selected part using a lifetime calculation equation for the selected part, wherein the lifetime calculation equation utilizes the service data and the operational data.

BRIEF DESCRIPTION OF THE DRAWINGS

These and other features of this invention will be more readily understood from the following detailed description of the various aspects of the invention taken in conjunction with the accompanying drawings in which:
FIG. 1 depicts an operational reliability system for managing reliability data from a plant in accordance with the present invention.
FIG. 2 depicts a data collection engine for collecting and processing dynamic plant data in accordance with the present invention.
FIG. 3 depicts a screen shot of dynamically displayed plant operational data in accordance with the present invention.
FIG. 4 depicts a screen shot of dynamically displayed plant status data in accordance with the present invention.
FIG. 5 depicts a screen shot of dynamically displayed plant status data in accordance with the present invention.
FIG. 6 depicts a screen shot of dynamically displayed ignition summary data in accordance with the present invention.
FIG. 7 depicts a screen shot of dynamically displayed engineering data in accordance with the present invention.
FIG. 8 depicts a screen shot of an operating report for a span of time in accordance with the present invention.
FIG. 9 depicts a system for dynamically calculating and outputting expended life data for parts within a plant in accordance with the present invention.
FIG. 10 depicts a screenshot of dynamically calculated and displayed equipment age data for parts within a plant in accordance with the present invention.

DETAIL DESCRIPTION OF THE INVENTION

1. Overview
The present invention describes a comprehensive system for collecting, analyzing, and presenting (collectively referred to as “managing”) reliability data for large-scale control systems. While the invention is described with reference to maintenance related data for a power system, it is understood that the concepts and inventive features described herein could be applied to managing any type of reliability data for any large-scale control system. For the purposes of this description, reliability data includes static data, e.g., parts information, service information, parts history, service history, maintenance schedules, etc., and dynamic data, e.g., operational information such as turbine speed, temperature, operating status, etc.
Referring now to FIG. 1, an operational reliability system 12 for managing reliability data from a plant 10 is shown. In this exemplary embodiment, data can be collected by system 12 either as static plant data 14 or as dynamic plant data 16. Static plant data 14 generally comprises parts or service data that does not change with respect to time, or only changes at infrequent intervals. Examples may include: (1) data collected by plant personnel to record ongoing maintenance and operations data, e.g., part removal and installation data, counter/age readings, etc.; (2) “as-built” configuration data that details parts, serial numbers, and description; (3) data collected by field service technicians to record major maintenance event data, etc. Static plant data 14 may be collected by system 12 in any manner, including via the web, via replication from a remote program or database, via a network batch job, etc. Static plant data 14 is inputted into operational reliability system 12 via a data entry engine 18, which stores the data to a central database 24.
Data in the central database 24 is made available to the client 26 in a non-dynamic fashion via an interactive interface 19. Interactive interface 19 provides various analysis, reporting and display systems for displaying data. Examples include parts tracking, service history, etc. Client 26 may access interactive interface 19 in any manner, e.g., via a network such as the Internet, etc.
Dynamic plant data 16 generally comprises raw operational data flowing directly from the plant 10 without human intervention. Dynamic plant data 16 captures various operational characteristics of plant 10 as a continuous stream of data. Dynamic plant data 16 may includes power output readings, fuel consumption readings, emissions readings, operational status, temperature readings, counter readings, trip data, ignition and start data, turbine speed, etc. In this exemplary embodiment, dynamic plant data 16 is delivered to system 12 via a dedicated network and is received via a data collection engine 20. Details of the data collection engine 20 are described below with reference to FIG. 2.
In addition to capturing the dynamic plant data 16, data collection engine 20 transforms (i.e., filters, analyzes and processes) the dynamic plant data 16 into a format that can be efficiently utilized by the operational reliability system 12. Specifically, the transformed dynamic data can be dynamically presented to the client 26 in a graphical user interface (GUI) 52 as near real-time operational data for the plant 10. In addition, the transformed dynamic data can be stored by the data entry engine 18 in central database 24.
Finally, operational reliability system 12 may include a dynamic part life calculation (DPLC) system 70 that is capable of dynamically calculating and outputting expended life information for parts. This feature is described in detail below with respect to FIG. 9.
2. Dynamic Data Collection
As noted above, operational reliability system 12 includes a data collection engine 20 for capturing dynamic plant data 16. Because of the large amount of near real-time dynamic data involved (e.g., thousands of data points each second), engine 20 must be able to capture, analyze and process the dynamic plant data 16 in an efficient manner. FIG. 2 describes an embodiment utilizing two separate computer processes for handling this task.
Dynamic plant data 16, which generally comprises a stream of binary data, is captured from plant 10 via a control system interface, and passed along an Ethernet connection to a remote computer system having data collection system 20 operating thereon. Within data collection engine 20, dynamic plant data 16 is temporarily buffered into data logs within one or more NT™ file folders 34. Specifically, dynamic plant data 16 is collected and passed to the NT file folders 34 using a “high-priority” computer process comprised of a data import program 32. Data import program 32 may be implemented, for instance, as an application programmers interface (API) using a combination of: (1) off-the-shelf data collection software that allows access through its native API libraries to a control system interface via standard drivers; and (2) a customized visual basic program. In addition, the data import program 32 can be configured such that any errors that occur are forwarded to a separate NT file folder 36 and stored as logging errors.
In an exemplary embodiment, data import program 32 dynamically creates SQL insert statements that capture all of the data points from the dynamic plant data 16. The insert statements are stored in a series of log files within an NT file system directory specified by data import program 32. Data import program 32 continuously logs the data in a “high priority” mode of operation, so that there is no interruption in the collection process. An example of an SQL insert record that provides date, time, identifier and value data is as follows:

- INSERT INTO analog_plant (point_datetime, point_id, local_entity_id, point_values) VALUES (‘Aug. 28, 2002 3:42:14 PM’,328,'1',65).

In a separate computer process, an NT service program 38 is run at a relatively lower priority to move the data logs to a core database 40. In particular, NT service program 38 checks the specified directory at specified time intervals for log files. If a log file exists, NT service program 38 opens the log file, reads the data, and submits it to the core database 40. After the submission is complete, NT service program 38 deletes the log file and moves on to a next log file. If no log file exists, NT service program 38 will idle until the data import program 32 writes another file to the specified directory. If NT service program 38 experiences an error during the submission of data to core database 38, the log file will be moved to a second directory (i.e., folder 36) for further investigation, preserving the data, but not hindering the ongoing process.
If the core database 40 becomes unavailable, or other unexpected issues arise causing the NT service program 38 to delay operations, no data is lost. The log files will continue to be written by the “higher priority” data import program 32 until any issues with respect to the NT service program 38 are corrected. Upon correction, the data can be written to the core database 40, thereby ensuring reliability and stability of the data collection engine 20. The data in this database is typically kept for about thirty days, although this can be customized and extended to a much longer time period as needed.
While the embodiment with reference to FIG. 2 is implemented using SQL insert statements, an NT file system, and an NT Service Program 38, it is understood that other database formats, operating systems, file structures and service programs could be utilized to perform the same functions without departing from the scope of the invention.
3. Data Transformation
After the data is stored in the core database, it is analyzed and processed by a transformation system 42 to generate transformed dynamic data 51. Transformation system 42 includes an event identification system 49 to identify core database inserts for specific events (i.e., “critical data points”). In particular, each data point is evaluated against certain criteria, as well as other data points, to determine if the information should be kept and/or processed. Critical data points may include any data points deemed important enough to save, display and/or process. Examples may include: critical events such as starts, ignition data, breaker closure, shutdowns, trips, aborted starts, etc.; operating states such as in startup, full speed no load, operating at base load, in shutdown, etc.; time based measurements of critical life parameters such as cycles and operating time at different load and temperature levels; operational parameters, such as fluid temperatures, turbine speeds, emissions, fuel flows, power output, etc., which will be collected at predefined intervals based on the unit's current operating status. Transformed dynamic data 51 is both passed along to a view database 48 where the data is replicated for a dynamic graphical user interface (GUI) 52 and to a database 50 for replication into the central database 24 via data entry system 18.
Database 50 contains transformed data that is used by the client to report data into the data entry engine 18. This transformed data provides a significant portion, e.g., about 75%, of the total input data required by the client and therefore decreases the time requirements placed on the plant personnel, while enhancing the accuracy of the resulting data. The data may be kept in database 50 permanently.
In some instances, critical data points are simply presented/saved as is. For instance, FIG. 3 depicts an exemplary screenshot of a viewing GUI 52 showing various critical data points (i.e., plant production data) for various plants within a single company. Critical data points, such as current power output (MW's), fuel type and burn rate are displayed and regularly updated in a near real-time fashion. FIG. 4 depicts a more detailed view of various readings for three units (GT01, GT02, GT03) at a single plant.
In other cases, the critical data points are further processed by data processing system 46 (FIG. 2) before being passed to the view database 48 and database 50. For example, critical data points may be used to calculate cumulative characteristics, such as total time on-line, total fuel consumption, number of starts, number of trips, energy generated over a span of time, etc. FIG. 5 depicts cumulative counter readings for the previous missions of the three units (GT01, GT02, GT03). Critical data points may also be processed to provide reports, such as an ignition summary (FIG. 6), engineering data such as blade path temperatures and turbine speeds (FIG. 7), and daily operating reports (FIG. 8).
In essence, transformation system 42 selects and processes critical data points. The resulting transformed dynamic data 51 can then be presented to the end-user (e.g., client) in near real-time via a dynamic GUI 52. From the dynamic GUI 52, the end-user is able to dynamically assess reliability data from a remotely located plant. In certain applications, dynamic GUI 52 can be configured to display reliability data from a plurality of plants, thereby allowing an end-user to monitor multiple disparate plant locations from a single site.
Expended Life Calculations
As noted above with reference to FIG. 1, Operational Reliability System 12 may include a dynamic part life calculation (DPLC) system 70 that is capable of dynamically calculating and outputting expended life information for parts. A more detailed DPLC system 70 is shown in FIG. 9.
At the heart of DPLC system 70 is life calculation engine 62 that utilizes both transformed dynamic data 60 and static data 53 to provide a dynamic output 64 that details expended life estimations for parts. It should be understood that for the purposes of this invention, the term expended life is broadly defined to include any information that describes or estimates an amount of used life/usefulness or remaining life/usefulness of a part.
Transformed dynamic data 60 may be obtained as described above, i.e., from dynamic plant data 16 collected via data collection engine 20, and processed via transformation system 42. Static data 53 may be obtained from central database 24, and will typically include information such as part number, installation dates, maintenance history, etc.
Life calculation engine 62 combines the dynamic operational information in the transformed dynamic data with the parts and service information in the static data to calculate expended life. For example, a given part, e.g., “1234,” installed in plant 10 can be identified, along with its associated installation date and service history across all other plants and units in which it was installed, from the static data 53. Transformed dynamic data 60 can then be used to provide any relevant operational information, such as hours of peak operation, hours of base operations, number of starts, number of trips, etc. A lifetime calculation equation can then be used to calculate and output expended life for the part dynamically in a near real-time manner.
In the exemplary embodiment of FIG. 9, dynamic output 64, which may include a date and time that the output was created, details two parts, “1234” and “xyz.” In this example, dynamic output 64 shows expended life (i.e., hour of peak and base operations), number of starts, and hours of remaining life for the two parts. In this case, each part is tracked by plant and unit. Thus, part 1234 is shown to have been used in Plant A Unit 1, Plant A Unit 2, and Plant B Unit 3. Usage information (i.e., hours, starts, etc.) is shown for each part over time, with the current location and usage information being shown in bold (i.e., Plant B Unit 3). Thus, part 1234 currently has 3200 peak and 12000 base hours of life remaining. Part xyz shows similar information, except that a repair was made to the part, which added 6000 peak and 12000 base hours. Part xyz currently has 4000 peak and 7000 base hours remaining.
Obviously, different types of expended life information can be presented without departing from the scope of the invention. Moreover, dynamic output 64 could be provided in any medium or format, e.g., within dynamic GUI 52, as a printed report, etc. A useful feature of DPLC system 70, however, is that expended life information can be made available for potentially any part within a plant “on demand” in a near real-time fashion.
As noted, life calculation engine 62 requires lifetime calculation equations to calculate expended life. Such equations are known in the art, and can be readily implemented. Most equations provide some interval (number of hours, starts, etc.) for which the part should be inspected, repaired or replaced. For instance, an “hours based” rotor life calculation for a GE® Frame MS7001/9001F and FA rotor is defined as follows: $Maintenance Factor = \frac{H + 2 * P + 2 * TG}{H + P}$ $Rotor Maintenance Interval = \frac{144000}{Maintenance Factor}$
Where: H=base load hours, P=peak load hours, and TG=hours on turning gear. In this case, a maintenance interval can be readily calculated and outputted. In addition, the remaining life or unused portion of the maintenance interval can be calculated and output. Other criterion, such as starts-based criterion for measuring a rotor maintenance interval could also be utilized and output.
FIG. 10 depicts a screenshot of dynamically calculated and displayed equivalent equipment age data in terms of hours and starts for two units GT01 and GT02. This information represents the expended life of the entire unit and, when combined with previous unit inspection data, can be used to determine and plan the future dates at which different inspections and module/part replacements must be performed. This particular example shows the unit age in terms of Factored Hours and Factored Starts equations, but the formula used to determine age might vary from unit to unit depending on the experiences of the owner/operator, the manufacturer of the equipment, and the results of each subsequent inspection.
It is also understood that the systems, functions, mechanisms, methods, and engines described herein can be implemented in hardware, software, or a combination of hardware and software. They may be implemented by any type of computer system or other apparatus adapted for carrying out the methods described herein. A typical combination of hardware and software could be a general-purpose computer system with a computer program that, when loaded and executed, controls the computer system such that it carries out the methods described herein. Alternatively, a specific use computer, containing specialized hardware for carrying out one or more of the functional tasks of the invention could be utilized. The present invention can also be embedded in a computer program product, which comprises all the features enabling the implementation of the methods and functions described herein, and which—when loaded in a computer system—is able to carry out these methods and functions. Computer program, software program, program, program product, or software, in the present context mean any expression, in any language, code or notation, of a set of instructions intended to cause a system having an information processing capability to perform a particular function either directly or after either or both of the following: (a) conversion to another language, code or notation; and/or (b) reproduction in a different material form.
The foregoing description of the preferred embodiments of the invention has been presented for purposes of illustration and description. They are not intended to be exhaustive or to limit the invention to the precise form disclosed, and obviously many modifications and variations are possible in light of the above teachings. Such modifications and variations that are apparent to a person skilled in the art are intended to be included within the scope of this invention as defined by the accompanying claims.

Claims

1. A data collection engine for collecting a stream of dynamic data from a plant, comprising:

a first computer process for receiving the dynamic data and for saving the dynamic data as database records in a series of log files within a file folder; and

a second computer process for reading the database records from the log files, and storing the database records in a database.

2. The data collection engine of claim 1, wherein the first computer process operates at a relatively higher priority than the second computer process.

3. The data collection engine of claim 1, wherein the second computer process deletes each log file after the database records are stored in the database.

4. The data collection engine of claim 1, further comprising a transformation system for evaluating data points in the stored database records to identify critical data points.

5. The data collection engine of claim 4, wherein the data points are evaluated against a predetermined criteria.

6. The data collection engine of claim 4, wherein the data points are evaluated against other data points.

7. The data collection engine of claim 4, wherein the critical data points are outputted to a second database and made available for viewing via a graphical user interface.

8. The data collection engine of claim 7, wherein the graphical user interface includes an interface for dynamically displaying a current operational status of the plant in near real-time.

9. The data collection engine of claim 7, wherein the graphical user interface includes an interface for dynamically displaying an ignition summary of a turbine unit at the plant.

10. The data collection engine of claim 7, wherein the graphical user interface includes an interface for displaying an operating report for the plant over a selected span of time.

11. The data collection engine of claim 7, wherein the graphical user interface includes an interface for displaying operational data for a turbine selected from the group consisting of: temperature, speed, emissions, trips, and starts.

12. The data collection engine of claim 7, wherein the critical data points are further outputted to a permanent database for secure storage.

13. The data collection engine of claim 1, wherein the database records comprise SQL insert records.

14. A method for collecting a stream of dynamic plant data, comprising:

using a first computer process to receive the dynamic plant data and to save the dynamic plant data as database records in a series of log files within a file folder; and

using a second computer process to read the database records from the log files and store the database records in a database.

15. The method of claim 14, comprising the further step of using the second computer process to delete each log file after the database records are stored in the database.

16. The method of claim 14, comprising the further step of evaluating data points in the stored database records to identify critical data points.

17. The method of claim 16, comprising the further step of dynamically outputting critical data points to a graphical user interface.

18. The method of claim 17, comprising the further step of outputting critical data points to a permanent storage database.

19. The method of claim 16, comprising the further step of processing critical data points to generate transformed data points.

20-26. (canceled)