semi合集-English.pdf - 第3695页

SEMI PR8-0703 © SEMI 2003 25 R2-1.1.4 Fault Detection and Classification (FDC) R2-1.1.4 .1 Scope of FDC Systems R2-1.1.4.1 .1 FDC systems are data-in tensive, time- critical applications. They typically collect process v…

100%1 / 7923
SEMI PR8-0703 © SEMI 2003 24
RELATED INFORMATION 2
EXAMPLE EDA CLIENT APPLICATIONS
NOTICE: This related information is not an official part of SEMI PR8. This related information is not intended to
modify or supersede the official proposed standard. Determination of the suitability of the material is solely the
responsibility of the user.
R2-1 Typical Users of Proposed EDA
Solutions
R2-1.1 This section provides a very basic overview of
the different classes of data collection clients that
proposed EDA implementations are intended to support
from the viewpoints of the types of data that are used,
and the basic dynamics of each client. The different
classes of data collection capabilities may be required
in a combination or separately depending on the
necessity.
R2-1.1.1 Equipment Utilization Tracking
R2-1.1.1.1 Scope of Utilization Tracking Applications
R2-1.1.1.1.1 Utilization tracking applications are
responsible for collecting information regarding the use
of the equipment in the factory. These applications
typically look for events and alarms/exceptions from
the to determine when the equipment is being
exercised, when it is idle, and when it is unable to
perform its intended function due to errors or alarms.
R2-1.1.1.2 Timeliness and Accuracy of Utilization
Data
R2-1.1.1.2.1 Such applications are not time-critical,
and can accept data off-equipment with very high
latencies (on the order of seconds to minutes or greater)
with no adverse effect on the ability of the application
to function. However, as these applications are meant
to calculate where the equipment is spending its time,
they require adequately accurate time stamping of all
events and alarms/exceptions. They also depend on the
equipment to properly communicate when tasks begin
and end, when alarms are set and when they are cleared,
etc. It is important for the equipment not to drop these
events, to double-count them, or to provide incorrect
timestamps for them.
R2-1.1.2 Equipment Health Monitoring
R2-1.1.2.1 Scope of Equipment Health Monitoring
Applications
R2-1.1.2.1.1 Equipment health monitoring applications
are responsible for collecting information regarding the
details of equipment operation, and to analyze
equipment operational data to detect or predict negative
trends in the performance of the equipment. These
applications will typically look for equipment
operational events describing the behavior of individual
subsystems, exceptions and alarms, trace data on select
parameters, and actuator status. The EDA interface
shall support a detailed level of equipment operations
that has not been conventionally supported so as to
achieve detailed equipment health monitoring or
diagnosis.
R2-1.1.2.2 Timeliness and Accuracy of Equipment
Health Data
R2-1.1.2.2.1 These applications are not time-critical,
and can accept data off-equipment with relatively high
latencies (on the order of seconds to minutes) with no
real adverse effect on the ability of the application to
function. They may be more reactive than utilization
tracking systems, looking for negative conditions on
which they may take some action (such as paging an
engineer, or warning of the need for a possible
maintenance run).
R2-1.1.3 Run-to-Run Control
R2-1.1.3.1 Scope of Run-to-Run Applications
R2-1.1.3.1.1 Run-to-Run applications are reactive
systems that collect process variable data from the
equipment (typically a metrology tool) at the end of a
run, and perform analysis on the results to determine if
any adjustments in control parameters shall be made to
future processing at the step that was measured. The
new settings are calculated and made accessible for
subsequent use at the corresponding process step.
R2-1.1.3.2 Timeliness of Run-to-Run Data
R2-1.1.3.2.1 These applications are not very time
critical in today’s systems, where control parameter
adjustments are performed on a lot basis. As it
becomes possible to collect measurement data on a
wafer basis, they will become more time-sensitive, and
may function properly with latencies on the order of
seconds.
R2-1.1.3.3 Run-to-Run Data Interests
R2-1.1.3.3.1 These applications are typically interested
in measurement result sets, events, exceptions, or
alarms.
SEMI PR8-0703 © SEMI 2003 25
R2-1.1.4 Fault Detection and Classification (FDC)
R2-1.1.4.1 Scope of FDC Systems
R2-1.1.4.1.1 FDC systems are data-intensive, time-
critical applications. They typically collect process
variable, event, and exception/alarm data from the
equipment as it’s produced, and analyze the results,
looking for faults that indicate or could lead to mis-
processing. If such a condition is detected, an FDC
system may send a control signal to the equipment
through the host, to abort processing before further
material is lost.
R2-1.1.4.2 Timeliness of FDC Data
R2-1.1.4.2.1 FDC applications can be very time
critical, sometimes in the sub-second range. As the
time criticality of FDC applications becomes more
acute, the ability of this interface to support these
applications will be severely tested.
SEMI PR8-0703 © SEMI 2003 26
RELATED INFORMATION 3
EQUIPMENT DATA LIFECYCLE
NOTICE: This related information is not an official part of SEMI PR8. This related information is not intended to
modify or supersede the official proposed standard. Determination of the suitability of the material is solely the
responsibility of the user.
R3-1 The Data Life Cycle
R3-1.1 The data originating from the equipment may be processed or converted into many forms depending on how
the data is to be utilized. The data obtained through the EDA interface will be processed by data consumers and
may be converted into a command that initiates certain control sequences, or perhaps converted into an STS or EPT
report. Other data obtained through the EDA interface will be linked together with JOB information (e.g. CJ, PJ,
carrier ID, slot ID, etc….) and used as process data. For APC purposes, process data and equipment health
monitoring data may be linked together to yield suitable APC/FDC engine input. The examples below show the
data life cycle steps from data generation to its consumption. The data through the same EDA interface can have
different data performance attributes such as data resolution depending on data, and may have different data life
cycle scenarios.
R3-1.1.1 Data Life Cycle Schematic
R3-1.1.1.1 The data life cycle schematic shows not only data acquisition but also utilization in many ways. The life
cycles shown in the diagram are all possible life cycle scenarios. Although this standard does not define all of the
life cycle scenarios (only scenarios #1 and #3), it is important this standard does not preclude other possible
scenarios such as data query and application calls. The A interface of an equipment may have all of these data life
cycle models depending on data utilization or applications.
1
2
3
4
re portStorage
Gene
-ration
Assort
-ment
1
re port
Gene
-ration
Assort
-ment
2
Storage
Assort
-ment
1
Gene
-ration
Storage
Assort
-ment
1
Assort
-ment
2-2
Storage
Assort
-ment
2-1
Assort
-ment
2
re port
Assort
-ment
2
re portStorage
Gene
-ration
Assort
-ment
2
Assort
-ment
1
Higher Level Interface
EDA Interface
re po rt
1
2
3
4
re portStorage
Gene
-ration
Assort
-ment
1
re port
Gene
-ration
Assort
-ment
2
Storage
Assort
-ment
1
Gene
-ration
Storage
Assort
-ment
1
Assort
-ment
2-2
Storage
Assort
-ment
2-1
Assort
-ment
2
re port
Assort
-ment
2
re portStorage
Gene
-ration
Assort
-ment
2
Assort
-ment
1
Higher Level Interface
EDA Interface
re po rt
Figure R3-1
The Data Life Cycles