ISMI Predictive Preventive Maintenance (PPM) Data Requirements

International SEMATECH Manufacturing Initiative

Technology Transfer #10105120A-TR
 Advanced Materials Research Center, AMRC, International SEMATECH Manufacturing Initiative, and
ISMI are servicemarks of SEMATECH, Inc. SEMATECH and the SEMATECH logo are registered servicemarks
of SEMATECH, Inc. All other servicemarks and trademarks are the property of their respective owners.

© 2010 International SEMATECH Manufacturing Initiative, Inc.

 ISMI Predictive Preventive Maintenance (PPM) Data Requirements
Technology Transfer #10105120A-TR
International SEMATECH Manufacturing Initiative
October 25, 2010

Abstract: This document from the MFGM032M project provides guidance for semiconductor equipment
suppliers, device makers, and other implementers of Prognostics and Health Management (PHM)
systems. The requirements for the integration of predictive and non-predictive condition-based
maintenance (CBM), scheduled preventive maintenance (PM), and maintenance optimizer
applications are discussed. The document introduces common language to describe the data
requirements and functionalities of the equipment and factory systems and uses examples to
justify extending existing PM factory systems to create an optimized maintenance system.
Note on Terminology: Predictive preventive maintenance (PPM) as a term is an invention of
ISMI. ISMI has defined PPM as “the integration of predictive maintenance (PdM), CBM, and
scheduled maintenance to optimize factory performance.” The broader industry-accepted term is
PHM, defined as “the discipline that links studies of failure mechanisms to system lifecycle
management.” The broader industry-accepted terms for PdM and CBM, as used by ISMI, are
predictive CBM and non-predictive CBM. In the interest of using broadly accepted terminology,
PHM, predictive CBM, and non-predictive CBM will be used throughout this document.

Keywords:

Authors: David Stark

Approvals: David Stark, Author

Sue Gnat, Technology Transfer Team Leader
 iii

Table of Contents

1 EXECUTIVE SUMMARY .....................................................................................................1

2 INTENDED AUDIENCE........................................................................................................1
3 BACKGROUND.....................................................................................................................1
4 INTEGRATION NOTE...........................................................................................................2
5 SUBSYSTEMS OF A COMPLETE PHM SYSTEM .............................................................2
5.1 Scheduled PM .................................................................................................................2
5.1.1 Basic Scheduled PM System Inputs and Outputs ...............................................3
5.1.2 Scheduled Maintenance Data Quality.................................................................5
5.2 Non-Predictive CBM ......................................................................................................6
5.2.1 Non-Predictive CBM Data Quality...................................................................10
5.3 Predictive CBM.............................................................................................................11
5.3.1 Predictive CBM Data Quality ...........................................................................15
5.4 Decision Making Application .......................................................................................15
5.4.1 Decision Application Data Quality ...................................................................16
6 PHM SYSTEM FACTORY ARCHITECTURE ...................................................................17
7 SUMMARY...........................................................................................................................19
8 REFERENCES ......................................................................................................................19
8.1 Documents ....................................................................................................................19
8.2 ISMI Programs/Project Material ...................................................................................19

ISMI Technology Transfer #10105120A-TR

iv

List of Figures

Figure 1 High Level View of PHM System..............................................................................3

Figure 2 Scheduled Maintenance System Example..................................................................4
Figure 3 Example of Health Indicator Visualization Output ....................................................9
Figure 4 Manual Visualization Job Build and Execution Example ..........................................9
Figure 5 Non-Predictive CBM System Functions and Libraries............................................10
Figure 6 Predictive CBM System Functions and Libraries ....................................................14
Figure 7 Predictive CBM User Set-Up and Manual Visualization Job Build and
Execution Example ..................................................................................................14
Figure 8 Decision Application Functions and Libraries .........................................................16
Figure 9 Integrated PHM System Data Flow .........................................................................18
Figure 10 PHM System Integrated to Fab Information ............................................................18

List of Tables

Table 1 Data Quality for Input and Output for Scheduled PM Module..................................5
Table 2 Data Quality for Input and Output for Non-Predictive CBM Module .....................11
Table 3 Data Quality for Input and Output for Predictive CBM Module .............................15
Table 4 Data Quality for Input and Output for Decision Application...................................17

Technology Transfer #10105120A-TR ISMI

 v

Acronyms and Abbreviations

AEC Advanced Equipment Control

ALID Alarm Event Identifier
AMHS Automated Material Handling System
APC Advanced Process Control
CBM Condition Based Maintenance
CD Critical Dimension
CEID Collection Event Identifier
CIM Computer Integrated Manufacturing
CMP Chemical Mechanical Polish
CVD Chemical Vapor Deposition
DCP Data Collection Plan
DOE Design of Experiments
DQ Data Quality
EDA Equipment Data Acquisition
EI Equipment Integration
EPI Equipment Performance Index
FDC Fault Detection & Classification
FICS Fab Information & Control System
IDM Integrated Device Manufacturer
ISMI International SEMATECH Manufacturing Initiative
JIT Just-In-Time
MES Manufacturing Execution System
MTTF Mean Time to Failure
NGF Next Generation Factory
OCAP Out of Control Action Plan
OEE Overall Equipment Efficiency
OEM Original Equipment Manufacturer
PCA Principal Component Analysis
PCR Principal Component Regression
PdM Predictive Maintenance
PHM Prognostics & Health Management
PLS Partial Least Squares
PM Preventive Maintenance
RUL Remaining Useful Life
SEMI Semiconductor Equipment and Materials International
SECS-II Semiconductor Equipment Communications Standards
SPC Statistical Process Control
SVID Status Variable Identifier
TBM Time-based Maintenance
UBM Usage-based Maintenance
WOM Wafer Oriented Manufacturing
YMS Yield Management System
UBM Usage-based Maintenance

ISMI Technology Transfer #10105120A-TR

vi

Definitions

 Advanced Process Control (APC) – Techniques covering both feed-forward and feedback
control and automated fault detection, applied by both the equipment (in situ) and by the
factory (ex situ).
 Degradation Rate – Rate at which the operational quality of an equipment system,
subsystem, or component decreases over time.
 Equipment Data Acquisition (EDA) – The suite of SEMI Diagnostic Data Acquisition (DDA)
standards; at this writing, the suite includes SEMI E120, E125, E132, and E134. Also
referenced by Interface A are SEMI E128 and E138.
 Equipment Performance Index (EPI) – Indicators composed of equipment hardware and/or
factory data. They can be used to calculate system/sub-system/component health metrics.
 Fault Detection & Classification (FDC) – A methodology of monitoring statistical variations in
processing tool data and detecting anomalies.
 Just-in-Time (JIT) Inventory – A strategy to improve the return on investment by reducing in-
process inventory and its associated carrying costs.
 Maintenance Event – Any activity (e.g., tests, measurements, replacements, adjustments
and repairs) intended to retain or restore a functional unit in or to a specified state in which
the unit can perform its required functions.
 Mean Time to Failure (MTTF) – The average time between failures with the modeling
assumption that the failed system is run until it fails without preventive maintenance.
 Out of Control Action Plan (OCAP) – A controlled document detailing the procedure to
disposition product/processes or equipment repairs or maintenance activities in response to
an equipment fault indication.
 Parameter Set – A set of related information that would likely be passed together as input
parameters to an operation request or output parameters in a corresponding response.
Specific examples include a process data set, a context data set, configuration data set,
etc. It is not intended to specify any aspect of the data’s persistent storage.
 Prognostics & Health Management (PHM) Information – The discipline that links studies of
failure mechanisms to system lifecycle management. PHM uses information to allow early
detection of impending or incipient faults, remaining useful life calculations, and logistical
decision-making based on predictions.
 Raw Data – Unprocessed data.
 Remaining Useful Life (RUL) – A forecast of time or operating cycles remaining until a
failure occurs.
 Run-To-Failure Methodology – A method whereby an equipment system, subsystem, and
component is fixed or replaced only after it fails.
 Sensor – A component that responds to changes in the physical environment and provides
an analog or digital output value.
 Subsystem – An intelligent aggregate that behaves as a unit. A subsystem is made up of
sensors and/or actuators and may contain mechanical assemblies. Multiple modules may
share subsystems.

Technology Transfer #10105120A-TR ISMI

 1

1 EXECUTIVE SUMMARY
This document provides guidance for semiconductor equipment suppliers, device makers, and
other implementers of prognostics and health management (PHM) systems. It introduces the
PHM system data requirements and functionalities to enable integration of the building blocks of
an intelligent maintenance system; predictive CBM, non-predictive CBM, scheduled preventive
maintenance (PM), and the maintenance decision making applications. Functionalities include
gathering equipment and factory data, assessing equipment health, assessing conditional states,
forecasting performance degradation, assessing scheduled PM calendars, optimized decision-
making, messaging, and visualization.
This document complements the 2008 Predictive Preventive Maintenance (PPM) Equipment
Implementation Guideline [1], the 2009 PPM Research White Paper [2], and the 2009 PPM
Implementation Guide [3].

2 INTENDED AUDIENCE
An integrated intelligent maintenance system is complex. It is comprised of multiple
interconnected building blocks, each of which may be developed by an equipment supplier, the
integrated device manufacturer (IDM), or third-party application suppliers. The audience for this
document consists of the building block developers, computer integrated manufacturing (CIM)
system integrators, equipment engineers, and factory management.

3 BACKGROUND
The objective of PHM is to maximize equipment return on investment. A PHM system will
optimize scheduled maintenance, predictive condition based maintenance, and non-predictive
condition based maintenance. Scheduled maintenance is performed on a fixed, calendar-based
schedule. Non-predictive condition-based maintenance is accomplished by instantaneous
monitoring of equipment and by performing maintenance when an equipment health indicator
reaches a predetermined threshold. Predictive condition based maintenance is accomplished
through acquiring relevant equipment and factory data and applying an equipment degradation
model to predict the equipment’s remaining useful life (RUL). A PHM system will combine
scheduled maintenance, condition-based maintenance, and predictive maintenance to enable
effective cost vs. performance decisions.
This document assumes a modular architecture to identify as many potential system interfaces
(and hence, data sources and destinations) as possible. The document scope will not address
other applications outside of the PHM building blocks, like FDC or APC, as either sources of or
destinations for PHM data.
ISMI has defined PPM as “the integration of predictive condition-based maintenance (CBM),
non-predictive CBM, and scheduled maintenance to optimize factory performance.” The broader
industry-accepted term is Prognostics and Health Management (PHM), defined as “the discipline
that links studies of failure mechanisms to system lifecycle management.” In the interest of using
broadly accepted terminology, PHM will be used throughout this document.

ISMI Technology Transfer #10105120A-TR

2

4 INTEGRATION NOTE
The optimum configuration for integration of the PHM system into a factory will depend on the
particular factory’s existing infrastructure. Even within the PHM system, the individual
subsystems may stand alone or be combined. It is likely that the decision application and the
scheduled maintenance system can be easily merged, since these two subsystems reside in the
factory and consume similar data. It is also likely that the non-predictive and predictive CBM
systems can be merged, since these two subsystems consume vast amounts of overlapping data
from equipment and factory and may reside closer to the equipment in the factory architecture.
This document will treat each subsystem of the PHM system as independent modules in the
interest of maximizing flexibility in integration. A large portion of this document will discuss the
modules of the complete system, their functions and libraries, and their place in the factory. This
discussion of each module will be followed by a list of the data entering and exiting the module
(i.e., the data flow). This data flow discussion will include a discussion of the data content and
data quality for each data flow.

5 SUBSYSTEMS OF A COMPLETE PHM SYSTEM

There are four subsystems of the complete PHM system: 1) preventive maintenance, 2) non-
predictive condition-based maintenance, 3) predictive condition-based maintenance, and 4) the
decision application. Each subsystem of the complete PHM system will be discussed. The data
input and output requirements for each subsystem will be described. Figure 1 shows a high level
view of the PHM system.

5.1 Scheduled PM
The scheduled PM system maintains a calendar of all scheduled PMs. Scheduled PMs are those
maintenance events that are scheduled on the basis of elapsed calendar time. In the
semiconductor factory, some of these scheduled PM events are monthly PM, quarterly PM,
semi-annual PM, and annual PM. The content and timing of these events are typically specified
by the OEM, and maintaining tools in accordance with the OEM specification is often a
condition of a warranty. Every predictive CBM and non-predictive CBM related maintenance
event will have a record in the database to which the CBM modules will write updated
information as those modules generate the associated signals.

Technology Transfer #10105120A-TR ISMI

 3

Decision Application Scheduled PM Application

A Rules Engine that calculates recommended maintenance A Calendaring Application that maps maintenance schedules
actions based on WIP scheduling scenarios and with various visualization types output. The outputs highlight
maintenance needs. Considers scheduled maintenance, recommended actions from the decision application, non-
predictive CBM RULs, and non-predictive CBM signals. predictive CBM signals, predictive CBM signals, manual
Contains: schedule changes, and the baseline schedule PM calendar.
• Rules Contains:
• Optimization scenarios • Scheduled PM schedule
• Visualizations • Visualizations
• Messaging • Maintenance Records
• User Input GUI • Messaging
• User Output GUI • User Input GUI
• User Output GUI

Predictive CBM Application Non-Predictive CBM Application

A real-time calculator that outputs a RUL of a tool leading to A real-time calculator that outputs a continuous health
a specific maintenance event. Uses an advanced assessment of equipment in the form of user-defined
mathematical model applied to data from equipment and equipment health indicators. Applies simple mathematics to
factory. equipment and factory data.
Contains: Contains:
• Models • Health Indicators
• Data requirement, model assigned, and threshold per • Data requirement, health indicator equation/function,
maintenance event threshold per health indicator
• Visualizations • Visualizations
• Messaging • Messaging
• Output to Scheduled PM System • Output to Scheduled PM System
• User Input GUI • User Input GUI
• User Output GUI • User Output GUI

Equipment Data Factory/Metrology Data

• Equipment Raw Data • MES Process Data

• OEM defined Health Indicators • Defects
• Parametric
• Yield Parameter

DCP from DCP Manager OR

Collect All Data Method DCP from DCP Manager OR
Collect All Data Method

Process Equipment Metrology Equipment

Figure 1 High Level View of PHM System

5.1.1 Basic Scheduled PM System Inputs and Outputs

The scheduled PM system is primarily a calendaring module. The system output is a calendar of
scheduled PM events for selected tools in graphical or tabular format. The system will allow
manual modification of the schedule to allow the user to change the schedule in response to
factory operational needs. Manual modifications should be indicated as such on the calendar.
ISMI Technology Transfer #10105120A-TR
4

Changes to the schedule should reseed the future date assignments for the scheduled
maintenance for the subject tool. Event IDs are unique to the event, such that multiples of the
same tool and model that require a common maintenance event have the same event ID. The
scheduled PM system is a factory-level system. In the event that OEM provided scheduled PM
systems are already in use, or elected for use, the output of the OEM systems will require
integration into the factory-level system. The OEM system, therefore, must output data in the
format required by the factory-level system. A pictorial representation of the scheduled PM
system is shown in Figure 2. In the figure, a manually rescheduled event is shown in the
scheduled maintenance calendar as m→m to denote that the monthly PM for the specified tool
was manually delayed. Unique events invoked by the predictive and non-predictive CBM
modules are also shown on the schedule. The required data from the CBM systems is the same as
for manual data input for the tool ID and event ID, but in place of a frequency the CBM system
passes a specific date.

Note: Showing information flow from scheduled and non-scheduled CBM systems through the scheduled maintenance system
and displayed on the scheduled maintenance calendar.

Figure 2 Scheduled Maintenance System Example

Technology Transfer #10105120A-TR ISMI

 5

5.1.2 Scheduled Maintenance Data Quality

The data flow into, out of, and inside the scheduled PM system relatively simple and low
frequency. The minimum requirements include identification of the source module, the
equipment unique ID, the maintenance event unique ID, and in the case of predictive CBM the
RUL confidence. In the graphical examples in Figure 2, these data elements are visualized
through color coding the “CBM RF1” event on Tool 1 and the “RUL.8 ESC1” event on Tool 3.
In the former case, the CBM RF1 event would be interpreted as the non-predictive CBM module
is recommending the RF1 unique maintenance event (e.g., replace the RF generator) on Tool 1
on the specified date. In the latter case, the RUL.8 ESC1 event would be interpreted as the
predictive CBM module is alerting that there is an 80% probability that the ESC1 unique
maintenance event (e.g., replace the ESC) is required on Tool 3 on the specified date. Where
there are recipe dependencies for the RUL predicted by the predictive CBM module, the worst
case will be mapped onto the schedule and the decision application will analyze the other
production—maintenance scenarios to show the production dependent options for the factory to
choose from. The predictive CBM module must pass the recipe dependent set of RULs to the
scheduled maintenance system, and the decision application will have to access the WIP queue
for the process step and the product-process associations to generate the options, and recommend
the WIP and maintenance schedule action based on the optimization scenario run. The product to
recipe associations must be available to the decision module, manually defined when setting up
the PHM system for the particular equipment and process step. The recipe identifiers should be
unique and shared by the PHM subsystems. Table 1 lists each of the input and output sources,
and the form, format, and items of the data required by the scheduled PM system.

Table 1 Data Quality for Input and Output for Scheduled PM Module
Data Source Type Purpose Form Format Items Special Notes
Manual Input Input Set-up Association Text strings, Tool ID, Event New strings
GUI table numerical ID, Frequency, need consistent
data, dates Entry Entity definition and
use (e.g., Entry
entity - CBM,
Event ID =
LamESC1)
Manual Input Input Maintenance Maintenance Text string, Tool ID, Event Removes event
GUI tracking performed date ID, Date or reseeds next
history table event timing
Manual Input Input Manual Maintenance Date Select Tool ID, Re-seeds next
GUI reschedule lookup table Select Event occurrence of
ID, enter date event
Manual Input Input Messaging set Messaging Text strings Distribution Associates
GUI up lookup table lists, events events to
messaging DLs
for consumption
by messaging
engine
User Request Input visualization Job guild input Menu Select Tool ID, Generates user
GUI Job stepwise selection, input start/end output report
Generation dates dates, select
visualization
type
Non-predictive Input Record update Association Text strings, Tool ID, Event For display in
CBM table numerical ID, Confidence schedule
data, dates RUL
generated
Date

ISMI Technology Transfer #10105120A-TR

6

Data Source Type Purpose Form Format Items Special Notes

Predictive CBM Input Record update Association Text strings, Tool ID, Event For display in
table dates ID, date schedule
Decision Input Record update Association Text strings, Tool ID, Event For display in
application table dates ID, date schedule
Visualizations Output Scheduling graphic or File File For display or
visualization table or list output

5.2 Non-Predictive CBM

A priority goal for the development PHM systems is to maximize CBM coverage for
maintenance events. The non-predictive CBM system directly monitors equipment health and
invokes maintenance actions when preset thresholds for a health indicator are reached. This
system will also track counters and invoke maintenance where the maintenance is performed on
the basis of usage (i.e. cumulative wafer count or process time). Calendar time-based
maintenance is not included in non-predictive CBM, as it resides in the scheduled PM system.
Non-predictive CBM implementation requires tool-specific development. Health indicators for
tools, tool modules, tool subsystems, and tool components will be unique to each OEM’s tool.
The source data within the equipment that is mathematically manipulated to derive health
indicators is unique to each OEM’s hardware, naming convention, and command and control
software. The development work to establish these health indicators may be performed by the
OEM, an IDM, a third party, or any combination of these parties. Health indicators and raw
equipment data will be consumed by the non-predictive and predictive CBM applications. In the
interest of efficient data transfer and storage, it is recommended that data be acquired once from
the equipment and then stored in an equipment data repository for consumption by applications,
such as CBM and FDC. This “collect data once” principle may require either a “collect all
equipment data” strategy or a data collection plan manager in the factory.
This document assumes that data collection for consumption by the CBM modules will be
managed outside of the application. The collected data that is needed by non-predictive CBM
modules will be “fetched” periodically as instructed manually or by a programmed periodic
visualization refresh. The form and format of the health indicators, and any source data from the
equipment should comply with SEMI E120, E125, and E134. Any derived health indicators,
calculated within the equipment envelope and exported to the equipment data repository for
consumption by CBM applications, must also be put in context consistent with SEMI E120,
E125, and E134. Factory data may be required to calculate health indicators. The association of
factory data to equipment data must be accomplished for successful CBM, and this association
can be accomplished using Lot ID and Wafer ID FOUP maps from the factory control system or
from the equipment, equipment onboard wafer ID readers, time stamps attached to equipment
data, or other strategies. A data synchronization tag is required to be attached to each data
element that the CBM module will access in the respective databases.
The non-predictive CBM application will reside outside the equipment envelope. This
requirement is necessary for the following reasons:
 The non-predictive CBM module will require factory data as input to the calculation of
equipment health indicators at some level of tool health assessment or for some
module/system/subsystem/component

Technology Transfer #10105120A-TR ISMI

 7

 The non-predictive CBM module will include a manual modification of thresholds at

the user’s discretion
 Factory-based applications are easier to propagate throughout the factory
User set up of the non-predictive CBM module requires:
 Equipment/module/subsystem/component hierarchy definition per SEMI E120/125/134
 Health indicator and counter list with association to equipment/module/subsystem/
component
 List of required data (equipment and factory) for each health indicator and counter
 Health indicator and counter calculation functions
 User-defined health indicator and counter thresholds
 Association of health indicator and counter trigger to maintenance event ID
 Messaging list per event (if messaging is active in this module)
Functions of the non-predictive CBM module are:
 Calculate health indicators and increment counters
 Associate health indicators and counters to equipment consistent with SEMI
E120/125/134
 Compare health indicators and counters to thresholds defined by the user
 Provide or invoke messaging of maintenance event triggered
 Provide visualization of equipment health status either continuously or upon manual
request for selected tools
 Provide input to scheduled PM system for calendar visualization including CBM
invoked maintenance events with scheduled PMs
Outputs of the non-predictive CBM module are:
 Messaging: Direct messaging of triggered maintenance event OR invoked message
command with relevant association information (tool ID, maintenance event ID)
 Visualization output to user via user interface: Equipment health dashboard, either real-
time continuously OR when manually requested for selected tools. Includes health
metric or counter value graphic versus threshold, current status and historical graphic
 Output to scheduled PM module: CBM invoked maintenance event with relevant tool
ID and maintenance event ID as input to scheduled PM module for calendar
visualization

ISMI Technology Transfer #10105120A-TR

8

User Interface – User Requests

 The user will access the system through the user interface to change any health indicator
or counter thresholds manually
 The user can manually request any health indicator or counter graphic output – select
from health indicator and counter library, select time period, select visualization type
from library.
An example output of a health indicator visualization (select X-Y graph for defined time period)
for one tool with two process chambers, four subsystems per chamber, and three components for
one chamber subsystem is shown in Figure 3. This particular example is for equipment: Lam
plasma etcher ID PET01; modules: Chambers A and B; subsystem: health indicators for vacuum
(VAC) and RF (RF) and gasbox (GAS) and temperature (TEMP); and the component: health
indicators for Chamber A Gasbox Gas1 and Gas2 and Gas3.
Figure 4 shows graphically a user request for health indicator visualization. From the figure, the
process is as follows (process step is denoted in the list below, and in Figure 4):
0. User accesses the CBM User Input GUI.
1. User selects a list of health indicators for visualization. The health indicators are stored
in the CBM health indicator library, with their associated contextual information per
SEMI E120/125/134, with all associated raw data required to construct the health
indicator, and with the specific health indicator calculation function. In the example,
user selected PET01/ChamberA/VAC, PET01/ChamberA/RF, PET01/ChamberA/GAS,
PET01/ChamberA/TEMP health indicators for visualization. This selection step results
in an assembled list of health indicators and their associated component data elements,
in a format that can be translated into a data extraction when merged with the time
period specified in step 3.
2. User selects the visualization type from a list of generic visualizations stored in the
library. In the example case, the user selected X-Y graph of health indicator vs. time.
3. User defines a time period. In the example the tile period is somewhat ambiguous, but
in a real example the time period is displayed on the X axis of the graphical output.
4. The CBM system builds the data extraction (termed data fetch) and gathers the data
from the equipment database and factory metrology database. This step involves two
processes. The first process involves the organization of the data extraction from the
CBM library information in step 1 and the time period specified in step 3 into a data
extraction plan. The second step is to execute the data extraction plan, which results in a
chronological tabular data file for health indicator generation.
5. The CBM system processes the chronological tabular data file from step 4 using the
calculation function from step 1, resulting in the chronological tabular data for each
health indicator selected organized for visualization.
6. The CBM system builds the user selected visualization from step 2 using the health
indicator data file from step 5. The CBM System outputs to the user the visualizations
requested.
Figure 5 shows a summary of the non-predictive CBM module functions and libraries.

Technology Transfer #10105120A-TR ISMI

 9

Figure 3 Example of Health Indicator Visualization Output

Process Equipment
USER

DCP from DCP Manager OR

User Input GUI
Collect All Data Method

CBM Libraries
Visualization Job Builder
• Health Indicators
1. Select Health Indicators • Visualizations
Equipment Data 2. Select Visualization Type • Message Distribution Lists
3. Define time period
• Equipment Raw Data
4. Build Data Fetch, execute Fetch
• OEM defined Health Indicators
5. Process Data with Health Indicator Function
6. Build Graphic & Display
Non-Predictive CBM
System Envelope

Metrology Equipment

Factory/Metrology Data

• MES Process Data

• Defects
• Parametric
• Yield Parameter

Figure 4 Manual Visualization Job Build and Execution Example

ISMI Technology Transfer #10105120A-TR

10

User Requests:
Adjust Specific Thresholds
Specific Virtualization Requests

User Input GUI Data Fetch Utility

functions
Calculate Health Indicators libraries
Compare to Threshold Health Indicator Library with Source Data List
Health Indicator Equations/Functions
Visualization Engine
Health Indicator Threshold & Event Association
Message or Invoke Message Visualization Library
Message Association to Maintenance Event
Output to Schedule PM System Message Distribution Lists

Figure 5 Non-Predictive CBM System Functions and Libraries

5.2.1 Non-Predictive CBM Data Quality

The data flow into, out of, and inside the non-predictive CBM system are complex. The majority
of the volume of data required for CBM is equipment sensor and factory metrology data. The
equipment data quality requirements depend on the specific equipment component, subsystem,
or module behavior that is being monitored using health monitors (or predictive algorithms in
predictive CBM). Data acquisition frequency is a known unresolved issue for some data needed
for CBM. Equipment-based special data acquisition may be needed to satisfy these extreme
requirements if sensitivity to performance features of these systems is to be accomplished, since
no current industry specification satisfies this requirement. RF systems, implanter sources, and
lithography illumination sources are a few examples where high frequency transients are of
interest, and to adequately acquire equipment data to sense these features requires data
acquisition at 1 kHz or higher. MFCs, vacuum control systems, and stage control are examples
where acquisition frequency of 10–100 Hz is required. Much of the rest of the required data,
such as robot position, valve position, and chamber pressure may be acquired at 1 Hz or less.
Simply put, the frequency at which data can be acquired determines the sensitivity of feature
detection available. Figure 1, Figure 3, Figure 4, and Table 2 show some of the inputs and
outputs of the non-predictive CBM module. Figure 5 shows the functions and libraries. Table 2
lists the various data inputs and outputs for the non-predictive CBM module. The data quality
requirements for the manually entered data are simply that all required fields are entered an in
the appropriate units or format. This is easy to police within the user input GUI, so that is the
recommended practice. The data coming to the non-predictive CBM system from the equipment
and factory will have a defined format and content consistent with the policies in practice at the
time in the factory. ISMI recommends use of the current Interface A suite of standards. The
scheduled PM module association table will include every non-predictive CBM module invoked
maintenance event that is developed. The non-predictive CBM module’s internal association
table sets the limits by which the CBM module acts on the scheduled PM system association
table, such that when the action threshold is reached the CBM module will write the invoked
maintenance action to the scheduled PM table for report out. A similar mechanism is used for
messaging.

Technology Transfer #10105120A-TR ISMI

 11

Table 2 Data Quality for Input and Output for Non-Predictive CBM Module
Data Source Type Purpose Form Format Items Special Notes
User Input GUI Input Set-up Association Text strings, Tool/component Unique
table SVIDs ID, Health equipment
indicator ID, health indicators,
source data IDs, the data
equation/function elements
required to
generate the
health indicator,
and the function
to use from the
function library
User Input GUI Input Threshold Association Text strings, Health indicator User sets health
setting and table numerical data ID, threshold, indicator
event maintenance threshold for
association event ID maintenance
set-up event trigger
and/or
messaging
trigger
Manual Input Input Messaging Messaging Text strings Distribution lists, Associates
GUI set-up lookup table events events to
messaging DLs
for consumption
by messaging
engine
User Request Input Visualization Job build input Manu Select Tool ID, Generates user
GUI job generation stepwise selection, health indicators, output report
dates input start/end
dates, select
visualization type
Maintenance Output Record update Association Text strings, Tool ID, Event For display in
trigger to table update dates ID, date schedule
scheduled PM
module
Visualizations Output Health Graphic or File File For display or
dashboard table or list output

5.3 Predictive CBM

High value and low frequency maintenance events are the focus of the predictive CBM module.
There should only be a few, perhaps ~5, of these cases on any tool. The predictive CBM system
directly monitors equipment health and predicts when a failure will occur that requires one of
these high value low frequency events. Prediction from predictive CBM is in the form of RUL of
the failing equipment. The RUL is in a form that can be used to jointly schedule maintenance and
production. RULs generated from a predictive algorithm will be either in units of calendar time,
process time, or wafers until the specific maintenance is required. A lookup table can be used to
convert the RULs in other units into number of wafers. In the case of recipe dependent
degradation, an RUL per recipe will be generated. The prediction output to the scheduled PM
system for visualization will include the full set of recipe dependent RULs. The decision
application will access the RUL set from the scheduled PM association table, access the WIP
queue for the tool with the WIP-recipe association, and make the joint schedule for WIP and
maintenance recommendation which, if accepted, will update the scheduled PM record. The
default schedule for the predictive CBM invoked maintenance event will be the earliest RUL
converted to calendar date, until either manually changed or changed by the decision application.

ISMI Technology Transfer #10105120A-TR

12

The large overlap in data requirements and functionality between non-predictive CBM and
predictive CBM leads to a conclusion that the modules may be merged into one CBM system.
Although this is logical, and time may prove that this is the preferred integration option, this
document will assume separate non-predictive and predictive CBM modules. This allows for
maximum flexibility, and addresses the significant differences in complexity (and thus required
expertise to develop) of health indicator development in non-predictive CBM and prediction of
RUL in predictive CBM.
Predictive CBM implementation requires tool-specific development. Predictive model
construction will be unique to each OEM’s tool. The source data within the equipment that is
consumed in the predictive models are unique to each OEM’s hardware, naming convention, and
command and control software. The development work to establish these models may be
performed by the OEM, an IDM, a third party, or any combination of these parties. Health
indicators, raw equipment data, and factory data will be consumed by the predictive CBM
application. In the interest of efficient data transfer and storage, it is recommended that data be
acquired once from the equipment and then stored in an equipment data repository for
consumption by applications, such as CBM and FDC. This “collect data once” principle may
require either a “collect all equipment data” strategy or a data collection plan manager in the
factory.
This document assumes that data collection for consumption by the CBM modules will be
managed outside of the application. The collected data that is needed by predictive CBM
modules will be “fetched” periodically as instructed manually or by a programmed periodic
refresh. The form and format of the health indicators, and any source data from the equipment
should comply with SEMI E120, E125, and E134. Any derived health indicators, calculated
within the equipment envelope and exported to the equipment data repository for consumption
by CBM applications, must also be put in context consistent with SEMI E120, E125, and E134.
Factory data may be required to calculate RULs. The association of factory data to equipment
data is accomplished as discussed in Section 5.2.
The predictive CBM application will reside outside the equipment envelope. This requirement is
necessary for the following reasons:
 The predictive CMB module will require factory data as input to the calculation of RUL
for some cases
 The predictive CBM module will include a manual modification of models at the user’s
discretion
 Factory-based applications are easier to propagate common elements of the application
throughout the factory
Figure 6 shows a summary of the predictive CBM module functions and libraries. Figure 7
shows user set-up and visualization job building example.
User set up of the predictive CBM module requires:
 Model list with output RUL association to equipment/module/subsystem/component
 List of required data (equipment and factory) for each predictive model
 Definition of the predictive models (modular code input to model library)

Technology Transfer #10105120A-TR ISMI

 13

 Association of RUL to maintenance event ID

 Threshold for each RUL to trigger messaging
 Messaging List per event (if messaging is active in this module)
Functions of the predictive CBM module are:
 Calculate RULs
 Compare RULs to thresholds defined by the user for messaging
 Provide or invoke messaging of RUL when RUL threshold is triggered
 Provide visualization of prediction either continuously or upon manual request
 Provide input to scheduled PM System for calendar visualization including predicted
maintenance events
Outputs of the predictive CBM module are:
 Messaging : Direct messaging of triggered maintenance event OR invoked message
command with relevant association information (tool ID, maintenance event ID, RUL,
confidence value)
 Visualization output to user via user interface: real-time continuously OR when
manually requested for selected tools. Includes RUL and recipe matrix with prediction
confidence interval and historical graphic
 Output to scheduled PM module: CBM invoked maintenance event with relevant tool
ID, maintenance event ID, RUL, and recipe matrix, and confidence values as input to
scheduled PM module for calendar visualization
User Interface – User Requests
 The user will access the system through the user interface to change any assignments
made in the user set-up section (above) including adjusting thresholds, messaging
distribution lists, etc
 The user can manually request any RUL set graphic output – select from event or fault
specific RUL library, select time period, select visualization type from library.
Output will be similar to that of the health indicator visualization shown in the non-predictive
CBM module section of this document.

ISMI Technology Transfer #10105120A-TR

14

User Requests:
Adjust Specific Thresholds
Specific Virtualization Requests

User Input GUI Data Fetch Utility

functions
Calculate RULs libraries
Compare to Thresholds RUL with Source Data List
Predictive Models
Visualization Engine
RUL Thresholds & Event Association
Message or Invoke Message Visualization Library
Message Association to Maintenance Event
Output to Schedule PM System Message Distribution Lists

Figure 6 Predictive CBM System Functions and Libraries

Process Equipment
USER

DCP from DCP Manager OR User Input GUI

User Request GUI
Collect All Data Method
Predictive CBM Libraries

• RUL + Source Data + Association Table Set-Up

Visualization Job Builder Thresholds + Event +
Model ID • Input Tool ID
1. Select Equipment + RULs • Models • Input Event ID
Equipment Data 2. Select Visualization Type • Input RUL ID
• Visualizations
3. Define time period • Message + Maintenance • Select Model
• Equipment Raw Data
4. Retrieve Data Event + Distribution List • Input/Select Source Data
• OEM defined Health Indicators
5. Build Graphic & Display • Input Thresholds + Actions (event, message)
• Repeat above steps

Messaging Table Set-Up

Predictive CBM • Select RUL
Metrology Equipment System Envelope • Input Unique Message
• Input/Select Distribution List

Factory/Metrology Data

• MES Process Data

• Defects
• Parametric
• Yield Parameter

Figure 7 Predictive CBM User Set-Up and Manual Visualization Job Build and
Execution Example

Technology Transfer #10105120A-TR ISMI

 15

5.3.1 Predictive CBM Data Quality

Please refer to Section 5.2.1. The same discussion applies to predictive CBM. Table 3 lists the
input and outputs for the predictive CBM module, with form, format, item list, and comments.

Table 3 Data Quality for Input and Output for Predictive CBM Module
Data Source Type Purpose Form Format Items Special Notes
User Input GUI Input Set-up Association Text strings, Tool/component Unique RULs,
table SVIDs ID, RULs, source the data
data IDs, Model elements
ID required to
generate the
RULs, and the
model to use
from the model
library
User Input GUI Input Threshold Association Text strings, RUL ID, User sets RUL
setting and table numerical data threshold, thresholds for
event maintenance maintenance
association event ID event trigger
set-up and/or
messaging
trigger
Manual Input Input Messaging Messaging Text strings Distribution lists, Associates
GUI set-up lookup table events events to
messaging DLs
for consumption
by messaging
engine
User Request Input Visualization Job build input Manu Select Tool ID, Generates user
GUI job generation stepwise selection, RUL, input output report
dates start/end dates,
select
visualization type
Maintenance Output Record update Association Text strings, Tool ID, Event For display in
trigger to table update date matrix ID, date-recipe schedule and
scheduled PM sets access by
module decision
application
Visualizations Output RUL Graphic or File File For display or
dashboard table or list output

5.4 Decision Making Application

The decision application uses a rules engine to determine the optimal maintenance schedule. The
inputs to the decision application are the existing schedule for scheduled PMs from the scheduled
PM module, including the non-predictive CBM data and predictive CBM data written to the
scheduled PM system, the factory parts inventory manager, maintenance event information
(duration, parts required, staff required—a lookup table), staffing, WIP schedules, WIP-recipe
associations, factory schedule, and other economic value drivers the IDM may elect to include
(e.g., value by product, lot priorities, etc.). The variety of data input to the decision application
will require a careful factory integration effort. The interconnectivity is expected to be different
depending on the particular factory’s system architecture. The IDM will set the decision rule
logic to maximize profits. It is expected that the IDM may define several reusable optimization
scenarios (e.g., maximize output, maximize profit, maximize hot lots, maximize utilization, etc),
and these reusable scenario rules sets will be stored in a library within the decision application
module. The decision application output is a recommended maintenance schedule. Multiple

ISMI Technology Transfer #10105120A-TR

16

scenarios may be run in session (or regularly scheduled to run), and the calendar views from of
the optimized and baseline schedules reported out for management. The IDM may elect to allow
the decision application to set maintenance schedules or may elect to retain manual control.
Maintenance schedules generated will highlights any changes with the source of the change
noted. Thus, if the CBM application output is that a specific maintenance event existing on the
schedule in the future is required immediately, and the decision application schedules that
maintenance immediately, then the recommended maintenance schedule should highlight that the
change was invoked by the CBM output and recommended by the decision application. Once the
maintenance event is performed, the “date performed” field in the maintenance record is updated
and the event record in the scheduled PM association table is reset to the post-tool-qualification
RUL.

User Requests:
Scenario Requests
Automation Set-Up

User Input GUI Data Fetch Utility

functions
libraries
Calculate Recommended Actions
Visualization Engine Rules Library
Optimization Scenarios
Messaging Visualization Library
Message Association to Decision Actions
Output to Schedule PM System
Message Distribution Lists

Figure 8 Decision Application Functions and Libraries

5.4.1 Decision Application Data Quality

The data flow into, out of, and inside the decision application system is relatively simple and low
frequency. The data quality requirements for the manually entered data are simply that all
required fields are entered an in the appropriate units or format. This is easy to police within the
user input GUI, so that is the recommended practice. The data coming to the decision application
system from factory control and management systems and the scheduled PM system will have a
defined format and content. The minimum requirements are that the data is available in the
format required by the rules engine as defined by the user. These are expected to be different at
each IDM, as each IDM has its own factory system terminology. Data sourced from the
scheduled PM system will be in the form and format discussed in that section of this document.
Messaging data is as discussed in the other modules.
Table 4 lists each of the input and output sources, and the form, format, and items of the data
required by the decision application system.

Technology Transfer #10105120A-TR ISMI

 17

Table 4 Data Quality for Input and Output for Decision Application
Data Source Type Purpose Form Format Items Special Notes
User Input GUI Input Rules set-up Rules table Text strings, Input unique rule Define rules
logicals, ID, select data
values ID, select logical
argument, select
value
User Input GUI Input Scenario Association Text strings Input scenario Define sets of
definitions table name, Select rules
rules from rules
tables
User Input GUI Input Automation set Auto Run table Text strings, Select scenarios, Runs selected
up data input frequency scenarios
(frequency) automatically at
frequency.
Extend to
automate output
Manual Input Input Messaging Messaging Text strings Distribution lists, Associates
GUI set-up lookup table events events to
messaging DLs
for consumption
by messaging
engine
User Request Input Visualization Job build input Manu Select Tool IDs, Generates user
GUI job generation stepwise selection, scenarios, time output report –
dates period, select calendar views
visualization type
Recommended Output Record update Scheduled PM Text strings, Tool ID, Event For display in
changes to association date matrix ID, date-recipe schedule output
events on table update sets
maintenance
schedule
Visualizations Output Scenarios Graphic or File File For display or
calendars table or list output

6 PHM SYSTEM FACTORY ARCHITECTURE

As stated in Section 4, factory integration of the PHM system is expected to be site specific.
Each of the modules described in this document can be combined with another module or be
divided and combined in various ways. It is logical to combine predictive CBM and non-
predictive CBM due to their common data requirements and similarity of functions. It is also
logical to combine the scheduled PM and decision applications due to their similar data
requirements and functions. Figure 9 and Figure 10 show the information flows between
modules. Application subcomponent reorganizations that have merit are to collocate the libraries
from all the modules, collocate the input and output GUIs for all the modules, etc. Each IDM in
consult with their internal or external integrator should map the elements of the PHM system
onto their factory architecture.

ISMI Technology Transfer #10105120A-TR

18

Figure 9 Integrated PHM System Data Flow

Figure 10 PHM System Integrated to Fab Information

Technology Transfer #10105120A-TR ISMI

 19

7 SUMMARY
PHM calls for a paradigm shift from scheduled preventive maintenance plus unscheduled
maintenance towards continuous, data-driven, condition-based monitoring using CBM strategies.
Proper application of these CBM strategies in a PHM system with joint production and
maintenance scheduling will allow the IDM optimize factory performance. Integration will
necessarily be a complicated IDM-specific challenge that can be eased only partially through
standardization or modular development strategies. Health assessment, degradation forecasting,
maintenance and production scheduling can be merged in a PHM system to raise maintenance
activities to next generation standards.

8 REFERENCES

8.1 Documents
 SEMI E120: Specification for the Common Equipment Model (CEM)
 SEMI E128: Provisional Specification for XML Message Structures
 SEMI E125: Specification for Equipment Self Description (EqSD)
 SEMI E132: Specification for Equipment Client Authentication and Authorization
 SEMI E134: Specification for Data Collection Management
 SEMI E138: XML Semiconductor Common Components
 SEMI E139: Specification for Recipe and Parameter Management (RaP)
 Various AEC/APC Conference Proceedings. (Asia, Europe, U.S., 2005-2008)
 W3C: XML Schema Part 2: Datatypes Second Edition

8.2 ISMI Programs/Project Material

[1] ISMI Predictive Preventive Maintenance (PPM) Equipment Implementation Guidelines
(SEMATECH Technology Transfer #08064934A-ENG)
[2] 2009 PPM Research White Paper from AWA (TTID 33662)
[3] 2009 Predictive Preventive Maintenance (PPM) Implementation Guideline (TTID
34009TD)

ISMI Technology Transfer #10105120A-TR

International SEMATECH Manufacturing Initiative
Technology Transfer
2706 Montopolis Drive
Austin, TX 78741

http://ismi.sematech.org
e-mail: info@sematech.org