U.S. patent application number 11/207087 was filed with the patent office on 2006-02-02 for system and method for processing control data.
Invention is credited to Garth Burrill, Thomas Christiansen, Salvatore A. JR. DellaVilla., Kevin Dunn, Robert JR. Steele, David Turpin.
Application Number | 20060026209 11/207087 |
Document ID | / |
Family ID | 31997637 |
Filed Date | 2006-02-02 |
United States Patent
Application |
20060026209 |
Kind Code |
A1 |
Burrill; Garth ; et
al. |
February 2, 2006 |
System and method for processing control data
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.
Inventors: |
Burrill; Garth; (Charlotte,
NC) ; Christiansen; Thomas; (Waxhaw, NC) ;
DellaVilla.; Salvatore A. JR.; (Charlotte, NC) ;
Dunn; Kevin; (Stanley, NC) ; Steele; Robert JR.;
(Charlotte, NC) ; Turpin; David; (Charlotte,
NC) |
Correspondence
Address: |
HOFFMAN WARNICK & D'ALESSANDRO, LLC
75 STATE STREET
14TH FL
ALBANY
NY
12207
US
|
Family ID: |
31997637 |
Appl. No.: |
11/207087 |
Filed: |
August 18, 2005 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
10403629 |
Mar 31, 2003 |
|
|
|
11207087 |
Aug 18, 2005 |
|
|
|
60408428 |
Sep 5, 2002 |
|
|
|
Current U.S.
Class: |
1/1 ;
707/999.107; 707/E17.009 |
Current CPC
Class: |
G06F 16/40 20190101;
G05B 23/0283 20130101 |
Class at
Publication: |
707/104.1 |
International
Class: |
G06F 17/00 20060101
G06F017/00 |
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)
Description
[0001] 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
[0002] 1. Technical Field
[0003] The present invention relates generally to processing
control data, and more particularly relates to managing reliability
data collected from an industrial plant.
[0004] 2. Related Art
[0005] 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.
[0006] 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.
[0007] 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.
[0008] 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
[0009] 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.
[0010] 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.
[0011] 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.
[0012] 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
[0013] 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:
[0014] FIG. 1 depicts an operational reliability system for
managing reliability data from a plant in accordance with the
present invention.
[0015] FIG. 2 depicts a data collection engine for collecting and
processing dynamic plant data in accordance with the present
invention.
[0016] FIG. 3 depicts a screen shot of dynamically displayed plant
operational data in accordance with the present invention.
[0017] FIG. 4 depicts a screen shot of dynamically displayed plant
status data in accordance with the present invention.
[0018] FIG. 5 depicts a screen shot of dynamically displayed plant
status data in accordance with the present invention.
[0019] FIG. 6 depicts a screen shot of dynamically displayed
ignition summary data in accordance with the present invention.
[0020] FIG. 7 depicts a screen shot of dynamically displayed
engineering data in accordance with the present invention.
[0021] FIG. 8 depicts a screen shot of an operating report for a
span of time in accordance with the present invention.
[0022] FIG. 9 depicts a system for dynamically calculating and
outputting expended life data for parts within a plant in
accordance with the present invention.
[0023] 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
[0024] 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.
[0025] 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.
[0026] 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.
[0027] 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.
[0028] 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.
[0029] 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
[0030] 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.
[0031] 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.TM. 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.
[0032] 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: [0033] INSERT INTO
analog_plant (point_datetime, point_id, local_entity_id,
point_values) VALUES (`Aug. 28, 2002 3:42:14 PM`,328,'1',65).
[0034] 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.
[0035] 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.
[0036] 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
[0037] 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.
[0038] 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.
[0039] 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.
[0040] 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).
[0041] 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
[0042] 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.
[0043] 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.
[0044] 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.
[0045] 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.
[0046] 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.
[0047] 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.
[0048] 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.RTM.
Frame MS7001/9001F and FA rotor is defined as follows: Maintenance
.times. .times. Factor = H + 2 * P + 2 * TG H + P ##EQU1## Rotor
.times. .times. Maintenance .times. .times. Interval = 144000
Maintenance .times. .times. Factor ##EQU1.2##
[0049] 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.
[0050] 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.
[0051] 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.
[0052] 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.
* * * * *