U.S. patent application number 11/839714 was filed with the patent office on 2009-02-19 for method for reporting the status of a control application in an automated manufacturing environment.
Invention is credited to Michael W. Mock, Gray R. Moore, Justin W. Wong.
Application Number | 20090048700 11/839714 |
Document ID | / |
Family ID | 40349388 |
Filed Date | 2009-02-19 |
United States Patent
Application |
20090048700 |
Kind Code |
A1 |
Mock; Michael W. ; et
al. |
February 19, 2009 |
METHOD FOR REPORTING THE STATUS OF A CONTROL APPLICATION IN AN
AUTOMATED MANUFACTURING ENVIRONMENT
Abstract
Disclosed are embodiments that provide near real-time monitoring
of a control application in a manufacturing environment to detect
and determine the root cause of faults within the control
application. The embodiments monitor the flow of data within the
control application during events (i.e., transactions, stages,
process steps, etc.). By comparing a dataflow path for a near
real-time event with historical dataflow path records, dataflow
interruptions (i.e., fails) within the control application can be
detected. By determining the location of such a dataflow
interruption, the root cause of the control application fail can be
determined. Additionally, the invention can generate summary
reports indicating the status of the control application. These
summary reports can further be generated with drill downs to
provide a user with direct access to the records upon which the
reports were based.
Inventors: |
Mock; Michael W.; (St.
George, VT) ; Moore; Gray R.; (Milton, VT) ;
Wong; Justin W.; (South Burlington, VT) |
Correspondence
Address: |
FREDERICK W. GIBB, III;Gibb Intellectual Property Law Firm, LLC
2568-A RIVA ROAD, SUITE 304
ANNAPOLIS
MD
21401
US
|
Family ID: |
40349388 |
Appl. No.: |
11/839714 |
Filed: |
August 16, 2007 |
Current U.S.
Class: |
700/110 |
Current CPC
Class: |
G05B 23/0278 20130101;
G05B 23/0227 20130101 |
Class at
Publication: |
700/110 |
International
Class: |
G06F 19/00 20060101
G06F019/00 |
Claims
1. A method for monitoring a control application, said method
comprising: accessing a plurality of data sources for said control
application; retrieving, from said data sources, data regarding
events occurring in a manufacturing environment monitored by said
control application; compiling said data to generate, for said
events, records of dataflow paths within said control application,
each of said records of said dataflow paths corresponding to a
specific event, indicating a type of said specific event and
further indicating at least one specific data source to which a
data posting was made during said specific event; storing said
records of said dataflow paths in a data storage device; and
performing an analysis of said records to detect a dataflow
interruption within said control application, said analysis
comprising comparing a current dataflow path record to historical
dataflow path records for same type events to identify differences
in data postings indicative of said dataflow interruption.
2. The method of claim 1, further comprising notifying a user of
said dataflow interruption.
3. The method of claim 1, further comprising generating a summary
report indicating a status of said control application based on
said analysis, wherein said summary report quantifies at least one
of performance and effectiveness of said control application.
4. The method of claim 3, wherein said generating of said summary
report comprises quantifying said performance of said control
application by indicating in said summary report at least a
percentage of said events for which said control application should
have collected said data and failed out of a total number of said
events.
5. The method of claim 3, wherein said generating of said summary
report comprises quantifying said effectiveness of said control
application by indicating in said summary report at least a
percentage of said events for which said control application had
inhibit ability out of a total number of said events.
6. (canceled)
7. The method of claim 1, wherein said performing of said analysis
further comprises analyzing said records to determine a location
within said control application of said dataflow interruption and,
based on said location, determining a root cause of a failure in
said control application.
8. The method of claim 1, wherein said performing of said analysis
further comprises analyzing said records in response to at least
one of a specific query and a continual query.
9. A method for monitoring a fault detection and classification
(FDC) application, said method comprising: accessing a plurality of
data sources for said fault detection and classification (FDC)
application; retrieving, from said data sources, data regarding
wafer-chamber passes in an integrated circuit manufacturing
environment monitored by said fault detection and classification
(FDC) application; compiling said data to generate, for said
wafer-chamber passes, records of dataflow paths within said fault
detection and classification (FDC) application, each of said
records of said dataflow paths corresponding to a specific
wafer-chamber pass and indicating at least one specific data source
to which a data posting was made during said specific wafer-chamber
pass; storing said records in a data storage device records; and
performing an analysis of said records to detect a dataflow
interruption within said fault detection and classification (FDC)
application, said analysis comprising comparing a current dataflow
path record for a given wafer-chamber pass to historical dataflow
path records for the same wafer-chamber pass to identify
differences in data postings indicative of said dataflow
interruption.
10. The method of claim 9, further comprising notifying a user of
said dataflow interruption.
11. The method of claim 9, further comprising generating a summary
report indicating a status of said fault detection and
classification application based on said analysis, wherein said
summary report quantifies at least one of performance and
effectiveness of said fault detection and classification (FDC)
application.
12. The method of claim 11, wherein said summary report quantifies
said at least one of said performance and said effectiveness of
said fault detection and classification (FDC) application by at
least one of tool type, technology, and technology center.
13. The method of claim 11, wherein said generating of said summary
report further comprises quantifying said performance of said fault
detection and classification (FDC) application by indicating in
said summary report at least a percentage of said wafer-chamber
passes for which said fault detection and classification (FDC)
application should have collected said data and failed out of a
total number of said wafer-chamber passes.
14. The method of claim 11, wherein said generating of said summary
report further comprises quantifying said effectiveness of said
fault detection and classification (FDC) application by indicating
in said summary report at least a percentage of said wafer-chamber
passes for which said fault detection and classification (FDC)
application had inhibit ability out of a total number of said
wafer-chamber passes.
15. (canceled)
16. The method of claim 9, wherein said performing of said analysis
further comprises analyzing said records to determine a location
within said fault detection and classification (FDC) application of
said dataflow interruption and, based on said location, determining
a root cause of a failure in said fault detection and
classification (FDC) application.
17. The method of claim 9, wherein said performing of said analysis
further comprises analyzing said records in response to at least
one of a specific query and a continual query.
18. A program storage device readable by computer and tangibly
embodying a program of instructions executable by said computer to
perform a method of monitoring a control application, said method
comprising: accessing a plurality of data sources for said control
application and retrieving, from said data sources, data regarding
events occurring in a manufacturing environment monitored by said
control application; compiling said data to generate, for said
events, records of dataflow paths within said control application,
each of said records of said dataflow paths corresponding to a
specific event, indicating a type of said specific event and
further indicating at least one specific data source to which a
data posting was made during said specific event; storing said
records of said dataflow paths in a data storage device; and
performing an analysis of said records to detect a dataflow
interruption within said control application, said analysis
comprising comparing a current dataflow path record to historical
dataflow path records for same type events to identify differences
in data postings indicative of said dataflow interruption; and at
least one of notifying a user of said dataflow interruption and
generating a summary report indicating a status of said control
application based on said analysis, wherein said summary report
quantifies at least one of performance and effectiveness of said
control application.
19. The program storage device of claim 18, wherein said performing
of said analysis further comprises analyzing said records to
determine a location within said control application of said
dataflow interruptions and, based on said location, determining a
root cause of a failure in said control application.
20. A service for monitoring a control application, said service
comprising: accessing a plurality of data sources for said control
application; retrieving, from said data sources, data regarding
events occurring in a manufacturing environment monitored by said
control application, each of said records of said dataflow paths
corresponding to a specific event, indicating a type of said
specific event and further indicating at least one specific data
source to which a data posting was made during said specific event;
compiling said data to generate, for said events, records of
dataflow paths within said control application; storing said
records of said dataflow paths in a data storage device; performing
an analysis of said records to detect a dataflow interruption
within said control application, said analysis comprising comparing
a current dataflow path record to historical dataflow path records
for same type events to identify differences in data postings
indicative of said dataflow interruption; and at least one of
notifying a user of said dataflow interruption and generating a
summary report indicating a status of said control application
based on said analysis, wherein said summary report quantifies at
least one of performance and effectiveness of said control
application.
Description
CROSS-REFERENCE TO RELATED APPLICATIONS
[0001] This application is related to the following co-pending
applications filed concurrently herewith by the same Applicants and
assigned to the same Assignee, namely, International Business
Machines Corporation (IBM Corporation): "A TOOL FOR REPORTING THE
STATUS OF A CONTROL APPLICATION IN AN AUTOMATED MANUFACTURING
ENVIRONMENT", Attorney Docket No. BUR920070078US1; "A METHOD FOR
REPORTING THE STATUS AND DRILL-DOWN OF A CONTROL APPLICATION IN AN
AUTOMATED MANUFACTURING ENVIRONMENT", Attorney Docket No.
BUR920070147US2; and "A TOOL FOR REPORTING THE STATUS AND
DRILL-DOWN OF A CONTROL APPLICATION IN AN AUTOMATED MANUFACTURING
ENVIRONMENT", Attorney Docket No. BUR920070147US1. The complete
disclosures of these related co-pending applications are
incorporated herein by reference.
BACKGROUND
[0002] 1. Field of the Invention
[0003] The embodiments of the invention generally relate to control
applications and, more particularly, to a system and method for
monitoring and reporting the status of a control application, such
as a fault detection and classification application, in an
automated manufacturing environment.
[0004] 2. Description of the Related Art
[0005] Advanced process control (APC) applications are increasingly
used in conjunction with manufacturing technology to improve
metrics, such as yield, costs, mean time between failures, etc. For
example, fault detection and classification (FDC) applications use
models to collect and monitor data regarding tool and/or process
parameters in order to provide an early warning of tool and/or
process faults and, thereby, to avoid having to scrap wafers or
entire lots of wafers. However, it is often difficult to identify
when a control application has failed or what the root cause of
such a control application failure might be. Specifically, it is
often difficult to monitor and quantify the effectiveness and
performance of a control application in real-time.
SUMMARY
[0006] In view of the foregoing, disclosed herein are embodiments
of a system, method, and service that provide near real-time
monitoring of a control application in a manufacturing environment
in order to detect and determine the root cause of faults within
the control application. The embodiments monitor the flow of data
within a control application during certain events (i.e., certain
transactions, stages, process steps, etc.). By comparing a dataflow
path for a near real-time event with historical dataflow path
records, dataflow interruptions (i.e., fails) within the control
application can be detected. By determining the location of such a
dataflow interruption, the root cause of the control application
fail can be determined. Additionally, the invention can generate
summary reports indicating the status of the control application
(e.g., over a given period of time). These summary reports can, for
example, quantify the performance of the control application (e.g.,
by indicating a percentage of events during a given period of time
for which the control application should have collected data and
failed) and/or quantify the effectiveness of the control
application (e.g., by indicating a percentage of the events during
a given period of time for which the control application had
inhibit ability). Additionally, these summary reports can be
generated with drill downs to provide a user with direct access to
the records upon which the reports were based.
[0007] More specifically, disclosed herein is an embodiment of a
system for monitoring an advanced process control (APC) application
(e.g., an fault detection and classification (FDC) application).
The system embodiment can comprise a data retriever adapted to
access a plurality of identified data sources (e.g., data logs and
databases) for the control application. The data retriever can
further be adapted to retrieve, from those data sources, all
relevant data regarding selected events (i.e., regarding selected
transactions, stages or process steps, such as selected
wafer-chamber passes). That is, each time a selected event (e.g., a
selected wafer-chamber pass) occurs on a new item (e.g., a wafer)
being manufactured, the data retriever will collect data that is
associated with that selected event and that is stored in the data
sources of the control application.
[0008] The system embodiment can further comprise a data compiler
adapted to compile this data in order to generate records of
dataflow paths within the control application for specific events.
Event dataflow path records can be time-stamped and stored by the
data compiler on a data storage device.
[0009] The system embodiment can further comprise a records
analyzer adapted to perform an analysis of the records (e.g., in
response to a specific query and/or automatically in response to a
continual query) in order to detect any dataflow interruptions
within the control application. Specifically, a comparison between
a dataflow path record for a current event (i.e., a near real-time
event) and historical dataflow path records (i.e., dataflow path
records of prior events of the same type) can be performed by the
analyzer to detect a dataflow interruption. The analyzer can
further be adapted to determine the locations of each of the
detected dataflow interruptions. Based on the location of a
dataflow interruption, the control application failure can be
classified.
[0010] The system embodiment can further comprise a summary report
generator and a graphical user interface (GUI). This summary report
generator can be adapted to generate a summary report indicating
the status of the control application (e.g., over a given period of
time), based on the records. More particularly, the summary report
can be generated based on the above-described analysis of the
records. The GUI can be used to display the report. For example,
the summary report generator can be adapted to generate a summary
report that quantifies the performance of the control application
(i.e., How well did the control application perform its functions?)
and/or the effectiveness of the control application (What is the
effective coverage of the control application?). In order to
quantify the performance of the control application, the summary
report can comprise the following entries: an entry that specifies
the total number of events, an entry that specifies the number of
events covered by a control application model, an entry that
specifies the number of broken arrows, an entry that specifies the
percentage of broken arrows, etc. In order to quantify the
effectiveness of the control application, the summary report can
comprise the following entries: an entry that specifies the total
number of events, an entry that specifies the number of events
covered by control application models, an entry that specifies the
best-case percentage of control application coverage, an entry that
specifies the number of events covered by control application
models where the control application had inhibit ability, an entry
that specifies the current percentage of coverage by control
application models, etc. Quantification of performance and/or
effectiveness of the control application can be based on some
user-specified or default grouping (e.g., in wafer processing the
grouping can be by tool type, by technology, by technology center,
by chamber, by recipe, etc.)
[0011] Additionally, the summary report generator can be adapted to
generate the summary report with drill down functions. Such drill
down functions can be used to allow a user to link via the GUI to
the records upon which the different line items in the summary
report are based.
[0012] Also disclosed herein are embodiments of a method and an
associated service for monitoring an advanced process control (APC)
application, such as a fault detection and classification (FDC)
application. Generally, the method embodiments can comprise
identifying and accessing a plurality of data sources (e.g., data
logs and databases) for the control application. The method can
further comprise retrieving, from those data sources, all relevant
data regarding selected events (i.e., data regarding selected
transactions, stages, process steps or the like within the
manufacturing environment, such as wafer-chamber passes). That is,
each time a selected event occurs (e.g., each time a selected
wafer-chamber pass is performed on a new wafer) all relevant data
that is associated with the selected event and that is stored by
the control application in its data sources will be collected. The
method can further comprise compiling this data in order to
generate records of dataflow paths within the control application
for specific events. Event dataflow path records can be
time-stamped and stored on a data storage device.
[0013] The method can further comprise performing an analysis of
the dataflow path records (e.g., in response to a specific query
and/or automatically in response to a continual query) in order to
detect any dataflow interruptions within the control application.
Specifically, the process of analyzing the records can comprise
performing a comparison between a dataflow path record of a current
event (i.e., a near real-time event) and historical dataflow path
records (i.e., the dataflow path records of prior events of the
same type) to detect a dataflow interruption. The process of
analyzing the records can further comprise analyzing the dataflow
path records to determine the location of each dataflow
interruption. Based on the location of the dataflow interruption,
the control application failure can be classified. Notification
(e.g., reports, alarms, etc.) can be provided to users of such
control application failures and their root causes.
[0014] In addition to detecting control application failures and
determining the root causes of those failures, the method can
comprise generating summary reports indicating the status of the
control application (e.g., over a given period of time), based on
the analysis of the records, and outputting or displaying (e.g., on
a graphical user interface (GUI)) the summary reports. For example,
each summary report can quantify the performance and/or the
effectiveness of the control application over a given time period,
as discussed above. Also, as discussed above, the summary report
can be generated according to some grouping (e.g., in wafer
processing the grouping can be by tool type, by technology, by
technology center, etc.). Furthermore, each summary report can be
generated with drill down functions allowing a user to link
directly to the dataflow path records, upon which the report was
based, using the GUI.
[0015] Finally, also disclosed are embodiments of a program storage
device readable by computer and tangibly embodying a program of
instructions executable by the computer to perform the
above-described method of monitoring a control application.
[0016] These and other aspects of the embodiments of the invention
will be better appreciated and understood when considered in
conjunction with the following description and the accompanying
drawings. It should be understood, however, that the following
descriptions, while indicating embodiments of the invention and
numerous specific details thereof, are given by way of illustration
and not of limitation. Many changes and modifications may be made
within the scope of the embodiments of the invention without
departing from the spirit thereof, and the embodiments of the
invention include all such modifications.
BRIEF DESCRIPTION OF THE DRAWINGS
[0017] The embodiments of the invention will be better understood
from the following detailed description with reference to the
drawings, in which:
[0018] FIG. 1 is a diagram illustrating and embodiment of the
system of the invention;
[0019] FIG. 2 is a table illustrating an exemplary technology
summary report;
[0020] FIG. 3 is a table illustrating another exemplary tool type
summary report;
[0021] FIG. 4 is a table illustrating yet another exemplary
technology center summary report;
[0022] FIG. 5 is a table illustrating an exemplary drill down from
a tool type summary report;
[0023] FIG. 6 is a table illustrating an exemplary drill down from
the table of FIG. 5;
[0024] FIG. 7 is a table illustrating an exemplary drill down from
the table of FIG. 6;
[0025] FIG. 8 is a flow diagram illustrating an embodiment of the
method of the invention;
[0026] FIG. 9 is a flow diagram illustrating another embodiment of
the method of the invention; and
[0027] FIG. 10 is a schematic diagram of an exemplary hardware
structure that may be used to implement the system and method of
the invention.
DETAILED DESCRIPTION OF EMBODIMENTS
[0028] The embodiments of the invention and the various features
and advantageous details thereof are explained more fully with
reference to the non-limiting embodiments that are illustrated in
the accompanying drawings and detailed in the following
description. It should be noted that the features illustrated in
the drawings are not necessarily drawn to scale. Descriptions of
well-known components and processing techniques are omitted so as
to not unnecessarily obscure the embodiments of the invention. The
examples used herein are intended merely to facilitate an
understanding of ways in which the embodiments of the invention may
be practiced and to further enable those of skill in the art to
practice the embodiments of the invention. Accordingly, the
examples should not be construed as limiting the scope of the
embodiments of the invention.
[0029] In view of the foregoing, disclosed herein are embodiments
of a system, method, and service that provide near real-time
monitoring of a control application in a manufacturing environment
in order to detect and determine the root cause of faults within
the control application. Specifically, the embodiments monitor
dataflow within a control application during certain events (i.e.,
certain transactions, stages, process steps, etc.) occurring in the
manufacturing environment. A comparison of the dataflow path for a
current event with the historical dataflow path records can be used
to detect dataflow interruptions (i.e., fails) within the control
application. The location of such a dataflow interruption can in
turn be used to determine the root cause of the control application
fail. Additionally, the system and method can generate summary
reports indicating the status of the control application (e.g.,
over a given period of time), based on the analysis of the records.
These summary reports can, for example, quantify the performance of
the control application (e.g., by indicating a percentage of events
during a given period of time for which the control application
should have collected data and failed) and/or quantify the
effectiveness of the control application (e.g., by indicating a
percentage of the events during a given period of time for which
the control application had inhibit). These summary reports can
further be generated with drill downs providing a user with direct
access to the records upon which the reports were based.
[0030] More specifically, referring to FIG. 1, disclosed herein is
an embodiment of a system 100 for monitoring an advanced process
control (APC) application (e.g., a fault detection and
classification (FDC) application, a run-to-run (R2R) application, a
model predictive control (MPC) application, sensor control and
feedback application, etc.). Such APC applications generally
collect data in a manufacturing environment and act (e.g., generate
reports, provide warnings, etc.) based on that data in order to
improve metrics, such as yield, costs, mean time between failures,
etc. Thus, associated with each control application are data
sources containing both raw and summary data.
[0031] For example, the system embodiment 100 can monitor a fault
detection and classification (FDC) application that uses sensors
and models to collect and monitor tool and/or process parameter
data in an integrated circuit manufacturing environment in order to
provide summary reports and early warnings of tool and/or process
faults and, thereby, to avoid having to scrap wafers or entire lots
of wafers.
[0032] The system embodiment 100 can comprise a data retriever 102
in communication with and adapted to access a plurality of
previously identified data sources 10 associated with the control
application. The data sources 10 can comprise, for example, data
logs and/or database containing data (e.g., logistic data, raw
data, summary data, etc.) acquired by the control application
during the manufacturing process. The data logs and/or databases
can be stored within storage devices of the various components of
the control application and/or within a central data warehouse
(e.g., a distributed manufacturing information warehouse (DMIW)).
Data sources 10 associated with the control application can
include, but are not limited to, the following: data sources 11
containing information from the machines supervisory program (MSP)
which provides a code interface between the tools and the
manufacturing execution system (MES); data sources 12 containing
information about the various tools used during events (i.e.,
transactions, stages, process steps, etc.) occurring in the
manufacturing environment; data sources 13 containing information
about the various recipes used in the manufacturing environment;
data sources 14 containing information about the control
application models used in the manufacturing environment; and data
sources 15 containing stored output (e.g., sensor records,
statistical process and control (SPC) charts, etc.) of the control
application in response to the different events that occur within
the manufacturing environment and that are covered by control
application models.
[0033] For example, if the manufacturing process is an integrated
circuit manufacturing process and if the control application is a
fault detection and classification (FDC) application which uses
statistical process control (SPC) techniques, the output data 15 of
the FDC application can be entries on SPC charts, in which sensor
data from the various manufacturing tools is recorded during a
given wafer-chamber pass. A wafer-chamber pass (i.e., a
recipe-wafer-chamber pass) refers to each time a single wafer is
placed in a chamber and processed within that chamber by one or
more tools according to one or more recipe-specific steps.
[0034] The data retriever 102 can further be adapted to retrieve,
from those data sources 10, all relevant data regarding selected
events (i.e., regarding selected transactions, stages or process
steps that occur during the manufacturing process, e.g., selected
wafer-chamber passes that occur during wafer processing). That is,
each time a selected event (e.g., a selected wafer-chamber pass)
occurs on a new item (e.g., a wafer) being manufactured, the data
retriever 102 will collect data that is associated with that
selected event and that is stored in the various data sources 10 of
the control application.
[0035] The system embodiment 100 can further comprise a data
compiler 104 in communication with the data retriever 102 and
adapted to compile this data in order to generate records 105 of
dataflow paths within the control application for specific events.
For example, the dataflow path records can show that every time a
specific event occurs (e.g., each time a given wafer-chamber pass
is performed on a new wafer), the same postings are made to the
same data sources. Event dataflow path records can be time-stamped
and stored by the data compiler 104 in a data storage device
106.
[0036] The system embodiment 100 can further comprise a records
analyzer 108 in communication with the storage device 106 and
adapted to access the records 105. The analyzer 108 is further
adapted to perform an analysis of the records 105 (e.g., in
response to a specific query and/or automatically in response to a
continual query) in order to detect any dataflow interruptions
within the control application. Specifically, a comparison between
a dataflow path record for a current event (i.e., a near real-time
event) and historical dataflow path records for prior events of the
same type previously stored in the in storage 106 can be performed
by the analyzer 108 to detect a dataflow interruption. That is,
such a comparison can be used to detect an interruption in the
known dataflow path for that event type, as established based on
the historical records stored in the data storage device. For
example, if the current event is a specific wafer-chamber pass
known to have control application model coverage and if, in the
past, this same wafer-chamber pass resulted in the posting of
certain data to a data source (e.g., a SPC chart), then no such
posting indicates that a dataflow interruption has occurred and,
thus, an control application failure has occurred.
[0037] The analyzer 108 can further be adapted to determine the
location within the control application of each dataflow
interruption. Based on the location of the dataflow interruption,
the control application failure can be classified. That is, a
determination can be made by the analyzer 108 as to the root cause
of the failure (e.g., a recipe error, model error, missing control
chart, etc.). For example, in a given control application the
dataflow path may be linear with data posting at different data
sources sequentially (i.e., with data posting at one data source,
then the next, and so on in succession). For example, in an
exemplary FDC application the dataflow path may be from a machine
supervisory program (MSP) to a process station for data acquisition
(PSDA) to a multivariate analysis engine (e.g., MAE) to a
disperser, to an SPC chart, etc. Since the flow of data is linear,
failure of the data to post at a given data source will indicate
that the failure has occurred upstream as opposed to downstream.
While the control application dataflow path, discussed above is
linear, non-linear (i.e., branching) control application dataflow
paths are also anticipated and those skilled in the art will
recognize that various logic applications can similarly be
developed to determine the location of the dataflow interruption in
such non-linear paths.
[0038] The system embodiment 100 can further a means by which a
user can be automatically notified of a detected control
application failure and, optionally, its location. For example, the
system can be adapted to send automatically generated emails, sound
alarms, etc., in order to notify a user of a detected control
application failure.
[0039] The system embodiment 100 can further comprise a graphical
user interface (GUI) 112 as well as a summary report generator 110
in communication with the analyzer 108, the data storage device 106
and the GUI 112. This summary report generator 110 can be adapted
to tally up various numbers within the records 105 in order to
generate summary reports 111 indicating the status of the control
application (e.g., over a given period of time), based on the
analysis of the records. Such summary reports 111 can be stored in
the data storage 106. The GUI 112 can be used to display the
summary reports 111 automatically or in response to user queries.
Specifically, the summary report generator 110 can, for example, be
adapted to generate a summary report 111 that quantifies, for a
given time period, the performance of the control application
(i.e., How well did the control application perform its functions?)
and/or the effectiveness of the control application (What is the
effective coverage of the control application?).
[0040] Quantification of performance and/or effectiveness of the
control application can be for a specified period of time and based
on some user-specified or default grouping (e.g., by technology
type, by tool type, by technology center, by chamber, by model, by
recipe, etc.) as specified in a user query.
[0041] For example, in integrated circuit manufacturing, one such
grouping can be by technology type. Technology type can be defined
as an aggregate of processes that define the manufacturing process
(e.g., in integrated circuit manufacturing, 300 mm technology
refers to processing of 300 mm wafers, 90 nm technology refers to
wafer processing during which the minimum gate width is 90 nm,
etc.). FIG. 2 provides a table illustrating an exemplary summary
report 200 by technology type 210 (300 mm technology) over a given
time period 215 (06/02/2007-06/08/2007), where column 220 specifies
different technologies within the 300 mm technology type (e.g., 130
nm Logic, 90 nm Logic, 45 nm Logic, etc.).
[0042] Another grouping in integrated circuit manufacturing can be
by tool type. Tool type can be defined as a collection of tools
that perform a similar process, for example, reactive ion etch
(RIE) tools contain both plasma etch and plasma strip tools. FIG. 3
provides a table illustrating an exemplary summary report 300 by
tool type 310 over a given time period 315 (06/02/2007-06/08/2007),
where column 320 specifies the different tools by tool
identification number (ID) and where each of the identified tools,
in this case, is within a given back end of the line reactive ion
etch (BEOL_RIE) tool type (i.e., a tool type that performs back end
of the line (BEOL) reactive ion etch (RIE) processes).
[0043] Yet another grouping in integrated circuit manufacturing can
be by technology center. Technology center can be defined as a
collection of process type (e.g., rapid thermal processing (RTP),
ion implantation (ION), chemical mechanical polishing (CMP), metal
film deposition (MTL), insulator deposition (INS), wet clean
processing (WET), plating (PLT), reactive ion etching (RIE),
furnace (FRN), etc. FIG. 4 provides a table illustrating an
exemplary summary report 400 by technology center 410 over a given
time period 415 (06/02/2007-06/08/2007), where column 420 specifies
different processes used.
[0044] In order to quantify the performance of the control
application, the summary report can comprise, for example, the
following entries, for each row beginning with a technology, tool
or technology center entry in the first column (see columns 220 of
FIG. 2, 320 of FIG. 3, and 420 of FIG. 4): (1) an entry that
specifies the total number of events performed in that technology,
by that tool, with that process, during the given period of time
(see columns 225 of FIG. 2, 325 of FIG. 3, and 425 of FIG. 4); (2)
an entry that specifies the number of events covered by control
application models (see columns 230 of FIG. 2, 330 of FIG. 3, and
430 of FIG. 4); (3) an entry that specifies the number of broken
arrows (i.e., the number of events performed in that technology, by
that tool or with that process, during the given time period, for
which the control application should have collected data and
failed); and/or (4) an entry that specifies the percentage of
broken arrows (i.e., the percentage of events performed in that
technology, by that tool or with that process, during the given
period of time, for which the control application should have
collected data and failed over the total number of events that
occurred during that same time period, see columns 250 of FIG. 2,
350 of FIG. 3, and 450 of FIG. 4), etc.
[0045] In order to quantify the effectiveness of the control
application, the summary report can comprise, for example, the
following entries, for each row beginning with a technology, tool
or technology center entry in the first column (see columns 220 of
FIG. 2, 320 of FIG. 3, and 420 of FIG. 4): (1) an entry that
specifies the total number of events performed in technology, by
that tool or with that process, during the given period of time
(see columns 225 of FIG. 2, 325 of FIG. 3, and 425 of FIG. 4); (2)
an entry that specifies the number of events covered by control
application models (see columns 230 of FIG. 2, 330 of FIG. 3, and
430 of FIG. 4); (3) an entry that specifies the best-case
percentage of control application coverage (i.e., an entry that
specifies the percentage of events covered by control application
models out of the total number of events, see columns 235 of FIG.
2, 335 of FIG. 3, and 435 of FIG. 4); (4) an entry that specifies
the number of events covered by control application models where
the control application had inhibit ability (see columns 240 of
FIG. 2, 340 of FIG. 3, and 440 of FIG. 4),; and/or (5) an entry
that specifies the current percentage of coverage by control
application models (i.e., the percentage of events during a given
period of time for which the control application had inhibit
ability out of the total number of events, see columns 255 of FIG.
2, 355 of FIG. 3, and 455 of FIG. 4), etc. Inhibit ability refers
to the control applications ability to stop (i.e., inhibit) the
process if a fail is detected (i.e., if a determination is made by
an FDC application that a given tool or process is outside set
parameters).
[0046] Additionally, the summary report generator 110 can be
adapted to generate summary reports with drill down functions. Such
drill down functions can be multi-tiered and can be used to allow a
user to link via the graphical user interface to the records upon
which the different line items in each summary report are based.
That is, referring to FIGS. 2-4, the various entries may be
selected providing additional details regarding, status, errors,
performance and coverage.
[0047] For example, from a tool type summary report a user may
select a specific Tool ID (e.g., JJ05) in order to pull up the
table of FIG. 5. The table of FIG. 5 breaks down the total number
of wafer chamber passes performed by tool ID JJ05, according to
different recipe-tool-chamber combinations. That is, each row
identifies the number of wafer-chamber passes performed by tool ID
JJ05, using the same recipe-tool-chamber combination. The first row
of FIG. 5 illustrates a recipe-tool-chamber combination in which
the recipe is new such that there is no comparison data for broken
arrow identification. However, the third row of FIG. 5 illustrates
a recipe-tool-chamber combination resulting in a broken arrow
(i.e., an error). From the table of FIG. 5, a user may select the
specific recipe-tool-chamber that resulted in an error (i.e., row
3) in order to pull up the table of FIG. 6. The table of FIG. 6
breaks down each of the wafer-chamber passes that were performed
using the error producing recipe-tool-chamber combination of row 3
of FIG. 5 by wafers. From the table of FIG. 6, a user may select an
individual wafer (e.g., 90K0IF3PKOF2) in order to pull up the table
of FIG. 7. The table of FIG. 7 provides the root cause details of
the error relative to that individual wafer.
[0048] Referring to FIG. 8, also disclosed herein are embodiments
of a method for monitoring an advanced process control (APC)
application (e.g., a fault detection and classification (FDC)
application, a run-to-run (R2R) application, a model predictive
control (MPC) application, sensor control and feedback application,
etc.) that collects data in a manufacturing environment and acts
based on that data in order to improve metrics, such as yield,
costs, mean time between failures, etc. Specifically, a broad
embodiment of the method can comprise identifying and accessing a
plurality of data sources for the control application (802). The
data sources can comprise, for example, data logs and/or databases
containing data (e.g., logistic data, raw data, summary data, etc.)
acquired by the control application during the manufacturing
process. These data logs and/or databases can be stored within
storage devices of the various components of the control
application and/or within a central data warehouse (e.g., a
distributed manufacturing information warehouse (DMIW)). The data
sources associated with the control application can include, but
are not limited to, the following: data sources containing
information from a machines supervisory program (MSP) which
provides a code interface between the manufacturing tools and the
manufacturing execution system (MES) (803); data sources containing
information about the various tools used during events (i.e.,
transactions, stages, process steps, etc.) occurring in the
manufacturing environment) (804); data sources containing
information about the various recipes used in the manufacturing
environment (805); data sources containing information about the
control application models used in the manufacturing environment
(806); and data sources containing stored outputs of the control
application (e.g., sensor records, statistical process and control
(SPC) charts, etc.) following events that occurs within the
manufacturing environment and that are covered by control
application models (807).
[0049] The method can further comprise retrieving, from those data
sources, all relevant data regarding selected events (i.e., data
regarding selected transactions, stages, process steps or the like
within the manufacturing environment, such as wafer-chamber passes)
(808). That is, each time a selected event occurs (i.e., each time
the transaction is performed on a new item, such as a wafer, being
manufactured) data that is associated with the selected event and
that is stored by the control application in its data sources will
be collected.
[0050] The method can further comprise compiling this data in order
to generate records of dataflow paths within the control
application for specific events (810). These dataflow path records
can show that every time a specific event occurs, the same postings
are made to the same data sources. Event dataflow path records can
be time-stamped and stored on a data storage device. (812)
[0051] The method can further comprise performing an analysis of
the dataflow path records (e.g., in response to a specific query
and/or automatically in response to a continual query) in order to
detect any dataflow interruptions within the control application
(814). Specifically, the process of analyzing the records can
comprise performing a comparison between a dataflow path record of
a current event (i.e., a near real-time event) and historical
dataflow path records (i.e., the dataflow path records of prior
events of the same type) to detect a dataflow interruption. That
is, such a comparison can be used to detect any interruption in the
known dataflow path for that event type, as established based on
the historical records stored in the data storage device. For
example, if a given event is known to have control application
coverage and if, in the past, this same event resulted in the
posting of certain data to the data sources, then no such posting
indicates that a dataflow interruption has occurred and, thus,
indicates that a control application failure has occurred. The
process of analyzing the records can further comprise analyzing the
dataflow path records to determine the location of each dataflow
interruption. Based on the location of the dataflow interruption,
the control application failure can be classified. That is, a
determination can be made as to the root cause of the failure
(e.g., a recipe error, model error, missing control chart, etc.).
Notification (e.g., reports, alarms, etc.) can be provided to users
of such control application failures and their root causes
(816).
[0052] In addition to detecting control application failures and
determining the root causes of those failures, the method can
comprise generating a summary report indicating the status of the
control application (e.g., over a given period of time), based on
the analysis of the records, and outputting or displaying (e.g., on
a graphical user interface (GUI)) the summary report (818). This
summary report can, for example, quantify the performance (819)
and/or the effectiveness (820) of the control application.
[0053] As discussed in detail above and illustrated in the
exemplary summary reports of FIGS. 2-4, the process of generating
the summary report can comprise quantifying the performance of the
control application by providing in the report one or more entries
that reflect how well the control application performed its
functions and/or quantifying the effectiveness of the control
application by providing in the report one or more entries that
reflect the coverage of the control application. Also as discussed
in detail above and illustrated in FIGS. 2-4, the summary report
can be generated according to some grouping (e.g., by tool type, by
technology, by technology center, etc.) (821). Furthermore, the
summary report can be generated with drill down functions allowing
a user to link directly to the dataflow path records, upon which
the report is based, using a graphical user interface (GUI)
(822-823).
[0054] Referring to FIG. 9, a more narrow embodiment of the method
can specifically monitor a fault detection and classification (FDC)
application that uses models to collect and monitor tool and/or
process parameter data in an integrated circuit manufacturing
environment in order to provide an early warning of tool and/or
process faults and, thereby, to avoid having to scrap wafers or
entire lots of wafers.
[0055] This embodiment can similarly comprise identifying and
accessing a plurality of data sources for the FDC application
(902). The data sources can comprise, for example, data logs and/or
databases containing data (e.g., logistic data, raw data, summary
data, etc.) acquired by the FDC application during wafer
processing. The data logs and/or databases can be stored within
storage devices of the various components of the FDC application
and/or within a central database (e.g., a distributed manufacturing
information warehouse (DMIW)). The data sources associated with the
FDC application can include, but are not limited to, the following:
data sources containing information from a machines supervisory
program (MSP) which provides a code interface between the
manufacturing tools and the manufacturing execution system (MES)
(903); data sources containing information about the various tools
used during wafer-chamber passes (904); data sources containing
information about the various recipes used during wafer-chamber
passes (905); data sources containing information about the FDC
models (906); and data sources containing stored output of the FDC
application (907). Specifically, if the FDC application uses
statistical process control (SPC) techniques, the output of the FDC
application can be SPC charts, in which sensor data from
manufacturing tools used during a given wafer-chamber pass is
recorded. As mentioned above, a wafer-chamber pass (i.e., a
recipe-wafer-chamber pass) refers to each time a single wafer is
placed in a chamber and processed within that chamber by one or
more tools according to one or more recipe-specific steps.
[0056] This embodiment can further comprise retrieving, from those
data sources, all relevant data regarding selected wafer-chamber
passes (908). That is, each time a selected wafer-chamber pass is
performed on a new wafer, data that is associated with the selected
event and that is stored will be collected from the data sources of
the FDC application.
[0057] This embodiment can further comprise compiling the collected
data in order to generate records of dataflow paths within the FDC
application for specific wafer-chamber passes (910). These dataflow
path records can show that every time a specific wafer-chamber pass
is performed on a new wafer, the same postings are made to the same
SPC chart. Event dataflow path records can be stored on a data
storage device.
[0058] This embodiment can further comprise performing an analysis
of the dataflow path records (e.g., in response to a specific query
and/or automatically in response to a continual query) in order to
detect a dataflow interruption within the FDC application (914).
Specifically, the process of analyzing the records can comprise
performing a comparison between a dataflow path record of a current
wafer-chamber pass (i.e., a near real-time wafer-chamber pass) and
historical dataflow path records for the same wafer-chamber pass to
detect a dataflow interruption. That is, such a comparison can be
used to detect an interruption in the known dataflow path for that
specific wafer-chamber pass, as established based on the records
stored in the data storage device. More specifically, if a specific
wafer-chamber pass is known to have FDC model coverage and if, in
the past, that same wafer-chamber pass resulted in the posting of
certain data to a SPC chart, then no such posting indicates that a
dataflow interruption has occurred and, thus, indicates that an FDC
application failure has occurred. The process of analyzing the
records can further comprise analyzing the dataflow path records to
determine the location of the FDC application failure. Based on the
location of the dataflow interruption, the FDC failure can be
classified. That is, a determination can be made as to the root
cause of the FDC failure (e.g., a recipe error, model error,
missing control chart, etc.). Notification (e.g., reports, alarms,
etc.) can be provided to users of such FDC application failures and
their root causes (916).
[0059] In addition to detecting FDC application failures and
determining the root causes of those failures, the method can
comprise generating a summary report indicating the status of the
fault detection and classification application (e.g., over a given
period of time), based on the analysis of the records, and
outputting or displaying (e.g., on a graphical user interface
(GUI)) the summary report (918). This summary report can, for
example, quantify the performance and/or the effectiveness of the
FDC application (919-920).
[0060] As discussed in detail above and illustrated in the
exemplary summary reports of FIGS. 2-4, the process of generating
the summary report can comprise quantifying the performance of the
FDC application by providing in the report one or more entries that
reflect how well the control application performed its functions
(919). In order to quantify the performance of the FDC application
the summary report can contain the following: (1) an entry that
specifies the total number of wafer-chamber passes performed in
that technology, by that tool or with that process, during the
given period of time (see columns 225 of FIG. 2, 325 of FIG. 3, and
425 of FIG. 4); (2) an entry that specifies the number of
wafer-chamber passes covered by FDC application models (see columns
230 of FIG. 2, 330 of FIG. 3, and 430 of FIG. 4); (3) an entry that
specifies the number of broken arrows (i.e., the number of
wafer-chamber passes performed in that technology, by that tool or
with that process, during the given time period, for which the FDC
application should have collected data and failed); and/or (4) an
entry that specifies the percentage of broken arrows (i.e., the
percentage of wafer-chamber passes performed in that technology, by
that tool or with that process, during the given period of time,
for which the FDC application should have collected data and failed
over the total number of wafer-chamber passes that occurred during
that same time period, see columns 250 of FIG. 2, 350 of FIG. 3,
and 450 of FIG. 4), etc.
[0061] Also, as discussed in detail above and illustrated in the
exemplary summary reports of FIGS. 2-4, the process of generating
the summary report can comprise quantifying the effectiveness of
the FDC application by providing in the report one or more entries
that reflect the coverage of the FDC application (920). In order to
quantify the effectiveness of the FDC application, the summary
report can contain the following: (1) an entry that specifies the
total number of wafer-chamber passes performed in that technology,
by that tool or with that process, during the given period of time
(see columns 225 of FIG. 2, 325 of FIG. 3, and 425 of FIG. 4); (2)
an entry that specifies the number of wafer-chamber passes covered
by FDC application models (see columns 230 of FIG. 2, 330 of FIG.
3, and 430 of FIG. 4); (3) an entry that specifies the best-case
percentage of FDC application coverage (i.e., an entry that
specifies the percentage of wafer-chamber passes covered by FDC
application models out of the total number of wafer-chamber passes,
see columns 235 of FIG. 2, 335 of FIG. 3, and 435 of FIG. 4); (4)
an entry that specifies the number of wafer-chamber passes covered
by control application models where the control application had
inhibit ability (see columns 240 of FIG. 2, 340 of FIG. 3, and 440
of FIG. 4); and/or (5) an entry that specifies the current
percentage of coverage by FDC application models (i.e., the
percentage of wafer-chamber passes during a given period of time
for which the FDC application had inhibit ability out of the total
number of wafer-chamber passes, see columns 255 of FIG. 2, 355 of
FIG. 3, and 455 of FIG. 4), etc. Inhibit ability refers to the
control applications ability to stop (i.e., inhibit) the process if
a fail is detected (i.e., if a determination is made by an FDC
application that a given tool or process is outside set
parameters).
[0062] Also as discussed in detail above and illustrated in FIGS.
2-4, the summary report can be generated according to some grouping
(e.g., by tool type, by technology, by technology center, etc.)
(921). Furthermore, the summary report can be generated with drill
down functions allowing a user to link directly to the dataflow
path records, upon which the report is based, using a graphical
user interface (GUI) (see FIGS. 5-7 and discussion above,
922-923).
[0063] In addition to the method embodiments, described above, also
disclosed herein are associated service embodiments in which the
method of the invention is specifically performed for another, for
example, performed by a computer service provider for a
manufacturing customer, usually for a fee.
[0064] The embodiments of the invention can further take the form
of an entirely hardware embodiment, an entirely software embodiment
or an embodiment including both hardware and software elements. In
an embodiment, the invention is implemented in software, which
includes but is not limited to firmware, resident software,
microcode, etc.
[0065] Furthermore, the embodiments of the invention can take the
form of a computer program product accessible from a
computer-usable or computer-readable medium providing program code
for use by or in connection with a computer or any instruction
execution system. For the purposes of this description, a
computer-usable or computer readable medium can be any apparatus
that can comprise, store, communicate, propagate, or transport the
program for use by or in connection with the instruction execution
system, apparatus, or device. The medium can be an electronic,
magnetic, optical, electromagnetic, infrared, or semiconductor
system (or apparatus or device) or a propagation medium.
[0066] Examples of a computer-readable medium include a
semiconductor or solid state memory, magnetic tape, a removable
computer diskette, a random access memory (RAM), a read-only memory
(ROM), a rigid magnetic disk and an optical disk. Current examples
of optical disks include compact disk--read only memory (CD-ROM),
compact disk--read/write (CD-R/W) and DVD.
[0067] A data processing system suitable for storing and/or
executing program code will include at least one processor coupled
directly or indirectly to memory elements through a system bus. The
memory elements can include local memory employed during actual
execution of the program code, bulk storage, and cache memories
which provide temporary storage of at least some program code in
order to reduce the number of times code must be retrieved from
bulk storage during execution.
[0068] Input/output (I/O) devices (including but not limited to
keyboards, displays, pointing devices, etc.) can be coupled to the
system either directly or through intervening I/O controllers.
Network adapters may also be coupled to the system to enable the
data processing system to become coupled to other data processing
systems or remote printers or storage devices through intervening
private or public networks. Modems, cable modem and Ethernet cards
are just a few of the currently available types of network
adapters.
[0069] A representative hardware environment for practicing the
embodiments of the invention is depicted in FIG. 10. This schematic
drawing illustrates a hardware configuration of an information
handling/computer system in accordance with the embodiments of the
invention. The system comprises at least one processor or central
processing unit (CPU) 10. The CPUs 10 are interconnected via system
bus 12 to various devices such as a random access memory (RAM) 14,
read-only memory (ROM) 16, and an input/output (I/O) adapter 18.
The I/O adapter 18 can connect to peripheral devices, such as disk
units 11 and tape drives 13, or other program storage devices that
are readable by the system. The system can read the inventive
instructions on the program storage devices and follow these
instructions to execute the methodology of the embodiments of the
invention. The system further includes a user interface adapter 19
that connects a keyboard 15, mouse 17, speaker 24, microphone 22,
and/or other user interface devices such as a touch screen device
(not shown) to the bus 12 to gather user input. Additionally, a
communication adapter 20 connects the bus 12 to a data processing
network 25, and a display adapter 21 connects the bus 12 to a
display device 23 which may be embodied as an output device such as
a monitor, printer, or transmitter, for example.
[0070] Therefore, disclosed above are embodiments of the invention
that provide near real-time monitoring of a control application in
a manufacturing environment in order to detect and determine the
root cause of faults within the control application. The
embodiments monitor the flow of data within a control application
during certain events (i.e., certain transactions, stages, process
steps, etc.). By comparing a dataflow path for a near real-time
event with historical dataflow path records, dataflow interruptions
(i.e., fails) within the control application can be detected. By
determining the location of such a dataflow interruption, the root
cause of the control application fail can be determined.
Additionally, the invention can generate summary reports indicating
the status of the control application (e.g., over a given period of
time), based on the analysis of the records. For example, the
summary reports can quantify the performance of the control
application (e.g., by indicating a percentage of events during a
given period of time for which the control application should have
collected data and failed) and/or can quantify the effectiveness of
the control application (e.g., by indicating a percentage of the
events during a given period of time for which the control
application had inhibit ability). These summary reports can further
be generated with drill downs to provide a user with direct access
to the records upon which the reports were based.
[0071] The information made available to users by the disclosed
embodiments (i.e., control application failure notices, root cause
of failure notices, summary reports and drill downs) will allow
users to act in order to ultimately improve yield and enhance
productivity. For example, this information may precipitate
rerouting of products to different tool types or technology centers
with control application coverage. Identification of tools with
control application coverage and maximizing use of such tools will
minimizes scrap events. The information will allow users to act in
order to optimize equipment utilization. That is, the information
may be used to track tool performance and availability statistics
for production control and management and further to make
production decisions, such as fab loading decisions. In an indirect
way, the information may be used to monitor equipment availability
(i.e., equipment up-time). Finally, the information may be used to
identify problem areas within the control application and to
prioritize repairs.
[0072] The foregoing description of the specific embodiments will
so fully reveal the general nature of the invention that others
can, by applying current knowledge, readily modify and/or adapt for
various applications such specific embodiments without departing
from the generic concept, and, therefore, such adaptations and
modifications should and are intended to be comprehended within the
meaning and range of equivalents of the disclosed embodiments. It
is to be understood that the phraseology or terminology employed
herein is for the purpose of description and not of limitation.
Therefore, while the embodiments of the invention have been
described in terms of embodiments, those skilled in the art will
recognize that the embodiments of the invention can be practiced
with modification within the spirit and scope of the appended
claims.
* * * * *