ISMI Predictive Preventive Maintenance (PPM) Data Requirements

Predictive Preventive Maintenance (PPM) Data Requirements International SEMATECH Manufacturing Initiative

Advanced Materials Research Center, AMRC, International SEMATECH Manufacturing Initiative, and 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.

Predictive Preventive Maintenance (PPM) Data Requirements 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. 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, 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 Programs/Project Material...19

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

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

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 inprocess 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.

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 decisionmaking, 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]. 1 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. 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.

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) nonpredictive 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.

3 Decision Application A Rules Engine that calculates recommended maintenance actions based on WIP scheduling scenarios and maintenance needs. Considers scheduled maintenance, predictive CBM RULs, and non-predictive CBM signals. Contains: Rules Optimization scenarios Visualizations Messaging User Input GUI User Output GUI Scheduled PM Application A Calendaring Application that maps maintenance schedules with various visualization types output. The outputs highlight recommended actions from the decision application, nonpredictive CBM signals, predictive CBM signals, manual schedule changes, and the baseline schedule PM calendar. Contains: Scheduled PM schedule Visualizations Maintenance Records Messaging User Input GUI User Output GUI Predictive CBM Application A real-time calculator that outputs a RUL of a tool leading to a specific maintenance event. Uses an advanced mathematical model applied to data from equipment and factory. Contains: Models Data requirement, model assigned, and threshold per maintenance event Visualizations Messaging Output to Scheduled PM System User Input GUI User Output GUI Non-Predictive CBM Application A real-time calculator that outputs a continuous health assessment of equipment in the form of user-defined equipment health indicators. Applies simple mathematics to equipment and factory data. Contains: Health Indicators Data requirement, health indicator equation/function, threshold per health indicator Visualizations Messaging Output to Scheduled PM System User Input GUI User Output GUI Equipment Data Equipment Raw Data OEM defined Health Indicators Factory/Metrology Data MES Process Data 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.

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

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

6 Data Source Type Purpose Form Format Items Special Notes Predictive CBM Input Record update Association table Decision application Input Record update Association table Visualizations Output Scheduling visualization graphic or table or list Text strings, dates Text strings, dates Tool ID, Event ID, date Tool ID, Event ID, date For display in schedule For display in schedule File File For display or 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

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 realtime 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

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.

9 Figure 3 Example of Health Indicator Visualization Output Process Equipment USER DCP from DCP Manager OR Collect All Data Method User Input GUI Equipment Data Equipment Raw Data OEM defined Health Indicators Metrology Equipment Visualization Job Builder 1. Select Health Indicators 2. Select Visualization Type 3. Define time period 4. Build Data Fetch, execute Fetch 5. Process Data with Health Indicator Function 6. Build Graphic & Display CBM Libraries Health Indicators Visualizations Message Distribution Lists Non-Predictive CBM System Envelope Factory/Metrology Data MES Process Data Defects Parametric Yield Parameter Figure 4 Manual Visualization Job Build and Execution Example

10 User Requests: Adjust Specific Thresholds Specific Virtualization Requests User Input GUI Data Fetch Utility functions Calculate Health Indicators Compare to Threshold Visualization Engine Message or Invoke Message Output to Schedule PM System libraries Health Indicator Library with Source Data List Health Indicator Equations/Functions Health Indicator Threshold & Event Association Visualization Library Message Association to Maintenance Event 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. 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.

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 table User Input GUI Input Threshold setting and event association set-up Manual Input GUI User Request GUI Maintenance trigger to scheduled PM module Input Input Messaging set-up Visualization job generation Association table Messaging lookup table Job build input stepwise Output Record update Association table update Visualizations Output Health dashboard Graphic or table or list Text strings, SVIDs Text strings, numerical data Text strings Manu selection, dates Text strings, dates Tool/component ID, Health indicator ID, source data IDs, equation/function Health indicator ID, threshold, maintenance event ID Distribution lists, events Select Tool ID, health indicators, input start/end dates, select visualization type Tool ID, Event ID, date Unique equipment health indicators, the data elements required to generate the health indicator, and the function to use from the function library User sets health indicator threshold for maintenance event trigger and/or messaging trigger Associates events to messaging DLs for consumption by messaging engine Generates user output report For display in schedule File File For display or 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.

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)

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.

14 User Requests: Adjust Specific Thresholds Specific Virtualization Requests User Input GUI Data Fetch Utility functions Calculate RULs Compare to Thresholds Visualization Engine Message or Invoke Message Output to Schedule PM System libraries RUL with Source Data List Predictive Models RUL Thresholds & Event Association Visualization Library Message Association to Maintenance Event Message Distribution Lists Figure 6 Predictive CBM System Functions and Libraries Process Equipment USER DCP from DCP Manager OR Collect All Data Method Equipment Data Equipment Raw Data OEM defined Health Indicators Metrology Equipment User Request GUI Visualization Job Builder 1. Select Equipment + RULs 2. Select Visualization Type 3. Define time period 4. Retrieve Data 5. Build Graphic & Display Predictive CBM Libraries RUL + Source Data + Thresholds + Event + Model ID Models Visualizations Message + Maintenance Event + Distribution List Predictive CBM System Envelope User Input GUI Association Table Set-Up Input Tool ID Input Event ID Input RUL ID Select Model Input/Select Source Data Input Thresholds + Actions (event, message) Repeat above steps Messaging Table Set-Up Select RUL 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

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

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 Calculate Recommended Actions Visualization Engine Messaging Output to Schedule PM System libraries Rules Library Optimization Scenarios Visualization Library Message Association to Decision Actions 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.

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

18 Figure 9 Integrated PHM System Data Flow Figure 10 PHM System Integrated to Fab Information

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. 19 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 Programs/Project Material [1] 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)

International SEMATECH Manufacturing Initiative Technology Transfer 2706 Montopolis Drive Austin, TX 78741 http://ismi.sematech.org e-mail: info@sematech.org