Process Control Systems: Integrated for Future

MM 5044-17

Process Control Systems: Integrated for Future Process Technologies Youssry Botros and Hazem Hajj Intel Corporation, Mail Stop RA3-250, 2501 N.W. 229th Street, Hillsboro, OR 97124 E-Mail: [email protected] ABSTRACT Process Control Systems (PCS) are becoming more crucial to the success of Integrated Circuit makers due to their direct impact on product quality, cost, and Fab output. The primary objective of PCS is to minimize variability by detecting and correcting non optimal performance. Current PCS implementations are considered disparate, where each PCS application is designed, deployed and supported separately. Each implementation targets a specific area of control such as equipment performance, wafer manufacturing, and process health monitoring. With Intel entering the nanometer technology era, tighter process specifications are required for higher yields and lower cost. This requires areas of control to be tightly coupled and integrated to achieve the optimal performance. This requirement can be achieved via consistent design and deployment of the integrated PCS. PCS integration will result in several benefits such as leveraging commonalities, avoiding redundancy, and facilitating sharing between implementations. This paper will address PCS implementations and focus on benefits and requirements of the integrated PCS. Intel integrated PCS Architecture will be then presented and its components will be briefly discussed. Finally, industry direction and efforts to standardize PCS interfaces that enable PCS integration will be presented.

1. INTRODUCTION As patterning dimensions decrease, die yield and performance become increasingly sensitive to smaller amounts of process variations [1]. To minimize variability, Process Control is applied to prevent excursions, improve yield, decrease non-product runs, reduce cycle time due to rework, and reduce equipment calibration and maintenance. Process control can be categorized as follows [2]: • Inline process control: Executed during wafer manufacturing and processing to ensure product quality and reduce wafer scrap and rework • Offline process control: Carried out after wafer processing is complete to improve process This paper will focus on inline process control and its implementations and applications. At the highest level, inline process control aims at rapid detection, classification, prediction, and correction of problems and/or non optimal performance during wafer processing. Inline process control involves responding to undesired levels of variability by taking the appropriate actions. Intel PCS implementations cover a wide range of applications, namely Run to Run (R2R) control, Fault Detection and classification (FDC), and statistical Process Control (SPC). Definitions of these applications and their features are described in the emerging PCS SEMI Standard [3]. Historically, PCS implementations have been developed, implemented and supported separately. They are usually disjoint and in most cases, they have limited sharing of data, interaction of components, and integration of functions and architectures. However, there is a great deal of commonality and overlap between them and as a result, many capabilities can be leveraged, shared and integrated. With Intel moving to nanometer technology nodes, there is a need for tighter process control, quicker capability/functionality development and deployment and higher manufacturing efficiencies. This can be achieved by facilitating data access, algorithm sharing and improving interactions between PCS implementations/applications through efficient integration. This paper will focus on the integration (functional and architectural) of PCS implementations. The paper will first give an overview about PCS in Section 2. Section 3 will detail PCS characteristics and

requirements. To justify the need for PCS integration, benefits of PCS integration will be outlined and briefly described in Section 4. After stating integration benefits, integrated PCS requirements will be summarized in Section 5. Intel integrated PCS Architecture that satisfies these requirements will be presented in Section 6, where the architecture topology will be described, hinting its components. Finally, Intel external approach to drive PCS standards that facilitate PCS integration will be described in Section 7. Section 8 will summarize conclusions.

2. OVERVIEW OF PROCESS CONTROL SYSTEMS As indicated in section 1, PCS implementations are mapped to R2R, FDC and SPC applications or systems. Each one has three basic elements, data collection, data manipulation or reduction, and data interpretation which usually results in decisions and/or actions. However, usage model may be different for each application. For example, FDC applications are usually implemented at the tool level, perform real time analysis on process data, manipulating larger amounts of data using multivariate analysis techniques to monitor the equipment. On the other hand, SPC applications may tackle metrology or post-process data, manipulating smaller amounts of data using univariate analysis techniques to monitor the health of a process, tool or Fab module. In general, each PCS implementation has three common elements: • Data Acquisition: wafer/lot, equipments/tool data are collected at one of the following phases of wafer processing: o During processing: real time (usually in-situ) data are collected to be analyzed in order to ensure that tool/process is running within specs. For example, temperature and pressure measurements may be collected during wafer processing to ensure excursion free environment and alarm users in case of mis-processing [7] o After processing: Post process data are collected to monitor the health of a process or a tool. As an example, overlay and critical dimension measurements are collected from metro tools and analyzed to determine if material will be passed, re-processed or scrapped [4]. Control actions may be taken to adjust/stop tool or hold lots [5] o Before processing: measurements are collected, analyzed and analysis results are employed to adjust the tool before next wafer, lot or batch is processed. Example: Analyzing metro data and feeding adjustments to tools before lots are processed [5] • Data Analysis: Computational methods, algorithms, statistical techniques are applied to the collected data, resulting in a reduced set of data points that enable users to make appropriate decisions [1], [2], [4]. • Decisions and actions: Based on analysis results, decisions can be made and actions may be triggered (if needed). Decisions may be wafer, lot, batch, or tool/equipment based [6-8]. Decisions may include material disposition (pass, fail or rework), tool shutdown, lot holding, and/or user notification. Also, based on analysis results, control actions may be invoked to adjust tool or change recipe. As can be seen, all PCS implementations handle data in a consistent way (collection, analysis, decisions and actions). That consistency leads to the introduction of the PCS analysis engine concept [3], [7]. Using this concept, any PCS implementation (R2R, FDC, SPC) can be modeled as an analysis engine with inputs representing measured and configuration data, and outputs representing results, decisions and actions [3]. The conceptual PCS Analysis Engine was the first diver of the integrated PCS [9], [13].

2

3. DETAILED CHARACTERISTICS OF PROCESS CONTROL SYSTEMS According to section 2, each PCS implementation has three basic elements for handling data (collection, analysis and disposition). In this section, requirements and chrematistics for each element are summarized. 3.1 Data collection Requirements/Characteristics: Data are collected from the tool (process or metrology) before being analyzed. Understanding data characteristics is essential to ensure that proper PCS implementations can be designed, and deployed, satisfying all requirements. Data collection characteristics and requirements include the following: o Sampling: Addresses the required sampling/polling rate for collected data o Step: Measures the required sampling step for wafers, lots and batches. Example: skip wafer, lot sampling or apply sampling each n wafers or lots o Size/Records: Indicates the expected number of records after a run (a run may be a wafer, a lot, or a batch) o Response/delay: Measures the time between data collection, analysis and decisions o Accessibility: Shows where data can be displayed and accessed (Fab, office or both) o Availability: Indicates data availability model o Display: Summarizes data display requirements o Storage: Specifies required databases for inline data storage o Retention: Measures how long inline system will hold data o Loading to offline systems: Determines delay between analysis completion and data loading to offline systems. Also, it indicates frequency of data loading o Configuration: Provides ability to configure data collection, analysis, decisions and display o Configuration management: Provides ability to audit a specific configuration, change it, review it, and copy/move it o Security: Defines the security model for accessing data o Consistency: Implies the need to have standard data packets for data consistency among PCS implementations 3.2 Data Analysis Requirements/Characteristics: Collected data are analyzed using computational models, statistical techniques and algorithms. The following list represents data analysis characteristics and requirements: o Timing: Covers the time window for analysis execution (before, during or after wafer, lot, or batch processing) o Disposition: Indicates if disposition and decisions will be wafer, lot or batch based o Trend: Shows entity variation or change over time, or tool o Smoothing: Applies data smoothing algorithms and techniques to collected measurements before analysis to reduce noise effects, outliers and measurement errors o Offline analysis: Implies inline analysis methods, algorithms, and codes availability for offline systems/applications 3.3 Data Disposition Requirements/Characteristics: After executing the analysis, measurements and data sets are reduced to few parameters that enable decision making. Data disposition characteristics and requirements include: o Stop tool: Means the ability to stop tool when an Out of Control condition (OOC) or excursion is detected. The tool may be stopped automatically or manually o Adjust tool and/or change recipe: Covers the ability to compensate for systemic variations by adjusting tool settings, changing recipes. Adjustments may manual or automated o Intervention: Involves actions taken by users to stop tool, change setting or manually affect processing based on the data analysis o Knowledge based decisions: Implies user ability to accept, reject, or change decisions and recommendations based on experience, tool behavior and process needs

3

4. BENEFITS OF INTEGRATED PROCESS CONTROL SYSTEMS With the rapid decrease in transistor dimensions, huge increase in manufacturing complexity, and the continuous need to improve yield and reduce cost, integration of PCS becomes necessary. PCS integration allows PCS implementations to be tightly coupled, functionally cascaded, architecturally streamlined and efficiently able to interact and perform data analysis and decisions. Benefits of PCS integration include: •

Enable cascading of PCS implementations: With the nanometer technology being introduced, frequency of out of specifications/control conditions and excursions are expected to increase due to the reduction of feature sizes. Thus, faster and robust responses to different sources of variations are required. That can be achieved via consistent functional and architecture cascading of PCS applications [7], [8], [14]. In this case, a specific application may perform analysis on the collected data before forwarding summary data to another application which executes a different function, recommending decisions and actions. As an example, temperature in a diffusion furnace can be tracked by an FDC application which feeds summary data to SPC. If a trend is detected (by SPC), an alarm may be generated, notifying users about this trend. Also, tool adjustment may be invoked via an R2R controller. This use case illustrates the need to integrate and cascade PCS applications.

•

Leverage functional commonalities between PCS implementations: Since PCS implementations have common elements for data handling, some data handling methods may be shared between PCS applications. As an example, data analysis can be utilized for more than one implementation. Computational methods, algorithms and codes can be shared between different applications, resulting in the following benefits: o Reducing or alleviating redundant capability, analysis methods or code development. An algorithm can be shared between various implementations or applications o Reducing the burden of supporting, upgrading, and maintaining multiple systems o Allowing utilization best in breed algorithms, and third party applications o Achieving quicker turn around for capability implementation since a specific capability may be developed and deployed once and shared by different PCS implementations

•

Leverage architectural commonalities between PCS implementations: Many PCS implementations have different architectures with limited components sharing. This will limit PCS ability to share data, algorithms and cascade functionalities. The benefits of leveraging architectural commonalities include: o Reducing or alleviating redundant development of many architectural components o Allowing a Framework based development for PCS. As a result, time and cost required for developing components will be reduced o Achieving quicker turn around for software and architecture implementation o Reducing time and effort spent in supporting various implementations

•

Provide cross system data access: Improved data accessibility between PCS implementations facilitate data sharing. As an example, an R2R application may access data from an FDC. The benefits of providing cross system data access include: o Reduction of point solutions required to transfer data between different systems o Robust integration of PCS implementations o Quicker response to out of specifications, out of control conditions

•

Allow integration of third party products user written scripts: Consistent design and deployment of the integrated PCS will permit third party applications integration via standardized interfaces. An example includes integrating the MATLAB package to the inline systems, allowing more analysis capabilities and algorithm utilization.

From the aforementioned benefits, we can deduce that efficient integration of PCS implementations is required for future technologies. To have an efficient integrated PCS system, another set of integration requirements will be documented and discussed in the following section.

4

5. INTEGRATED PROCESS CONTROL SYSTEMS REQUIREMENTS In this section, PCS integration requirements will be summarized. Each one can be categorized either user or architectural. User requirements usually related to the functional utilization of the system while architectural ones are related to the automation aspect. 5.1 Functional (user) Integration Requirements: Functional integration requirements are usually mapped to the system usage and capabilities granted to users. These requirements include the following: o Analysis sharing between implementations/applications: This means that analysis methods, statistical techniques, algorithms, models and computational libraries can be shared o Data sharing between implementations/applications: This allows moving and accessing data between implementations. For example, an R2R system can access data that is stored in the SPC system to perform analysis o Data correlation between PCS implementations/applications: This provides ability to correlate data and conditions in different applications. As an example, SPC results can be correlated to FDC data, helping users to understand the root cause and trouble shoot a specific problem o Integration with third party applications: This allows utilization of third party tools and algorithms to analyze data. For example, MATLAB algorithms, functions and libraries can be applied to collected data 5.2 Architecture (automation) Integration Requirements: Architectural integration requirements include the following: o Three Tier Architecture (UI, business logic and database layers) o Consistent Platform, Databases, UI, and Middleware for PCS implementations o Consistent Control History (offline) Databases for PCS implementations o UI integration with results, graphs and charts from more implementation presented in one display. Also, same look and feel for all PCS implementations user interfaces is required o Extensibility which facilitates adding capability, implementing new analysis methodologies o Scalability to allow handling large numbers of lots, machines, and part types o Flexibility to handle a wide range of PCS application types and capabilities o Reliability that keeps all applications running with minimal break possibilities Based on the integration requirements presented in this section and the PCS detailed ones presented in Section 3, Intel integrated PCS architecture was designed to meet all challenges introduced by the future nanotechnology. Intel integrated PCS Architecture will be discussed in the following section.

6. INTEGRATED PCS ARCHITECTURE The section will detail Intel Integrated PCS Architecture which integrates existing and future process control implementations [7-9], [13]. In the section, the integrated PCS topology diagram will be presented and its component will be briefly discussed. 6.1 Integrated PCS Architecture: The Integrated PCS Architecture must be an open one, allowing internal and external access of process control data. Internal data access involves intra-PCS data availability. That means that data can be shared between different PCS implementations. External data access involves sharing process control data with external systems such as the Manufacturing Execution System (MES) and the Decision Support Systems (DSS). From functional (usage) point of view, the integrated PCS Architecture should handle real-time highvolume data processing and should be easily integrated with other automation systems, such as the manufacturing Execution System (MES), Equipment Interface (EI) or Station Controller (SC) systems, and offline analysis systems. Also, it should achieve high level of reliability, availability, performance, and scalability since PCS are usually mission critical in semiconductor Fabs.

5

From the architectural (automation) point of view, an integrated PCS architecture should support the central configuration of manufacturing process controls, provide flexibility in integrating third-party applications, and have clear interfaces defined. To allow and support the development, integration and upgrades to PCS implementations, a Framework based implementation is recommended with shared components that can be (re)used for all PCS implementations [9], [13]. To summarize, the design goals for an integrated PCS Architecture include [9]: o Open architecture, providing building block capability implementation, allowing use and reuse of building block functions o Provide wrapper like function/protocols to integrate third party applications o Provide hooks for graphics management, logging, tracking, and troubleshooting functions o Present a consolidated view of systems and tools to the end users ƒ Configuration should be managed in one central place if possible ƒ Exporting of data and/or charts to commercial software packages ƒ Similar look and feel of Graphical User Interface (GUI) across PCS implementations ƒ Data in offline systems should be in synch with online database, with minimal latency ƒ System access should be available to end users, both in fab and office environments o EI/SC should be decoupled from PCS: ƒ EI/SC should have no knowledge of specific components of PCS and talks to PCS in one format ƒ Default data format should be XML unless there is a compelling reason not to use it such as performance concern under high data rate

Presentation

Integration logic (workflow)

PCS EX UI

Common Data /Analysis Interfaces 3rd party

R2R FDC

PCS CFG UI

PCS Server

SPC

DPCS

Common Services (Reaction, computational engine etc)

PCS Executor

Tool

Tool

Tool

(Eqpt Interface) Station Controller

SC client CFG

Business Logic

MES

FDC

Vendor App

DSS Server

PCS Offline Systems

Offline DB

DB

Vendor

FDC

SPC

R2R

Data Collection Plans

SPC

PCS Shared Framework

CDR

Database

R2R

DB Initialization, PCS Data Publish

Figure1: Intel Integrated PCS Architecture

As shown in Figure 1, the integrated PCS Architecture consists of the following: • Client: There are three clients; the first is the EI/SC one which interacts with PCS system (sending and receiving data). The second is the configuration UI (PCS CFG UI) which allows users (automation,

6

• •

process, and control engineers) to configure the database. The third is the execution UI (PCS EXUI) which is designed to display PCS data and get user input. Middle Tier: The middle business logic tier is responsible for determining which component and implementation (R2R, FDC or SPC) to call, accepting data or providing data. Database Layer: is responsible for storing configuration and runtime data.

6.2 Components of the Integrated PCS Architecture: As displayed in Figure 1, Intel integrated PCS Architecture has the following components: • PCS Execution User Interface (PCS EX UI): Displays run time data to users, receives input from users. • PCS Configuration User Interface (PCS CFG UI): Allows users to configure data in the database and allows administrators to control access and user privilege to PCS system. • Configuration (CFG): Exposes interfaces to add/delete/modify data collection plans which are stored in configuration database. • Distributed PCS (DPCS): Provides interfaces to the EI so it can send data or make data request. It also provides PCS services for high bandwidth needs (larger amounts or highly sampled equipment data) to avoid sending high bandwidth data over the network. In addition, it provides UI services to the server applications. This component determines which subcomponent to call and if the call needs to go to the PCS server. It provides the framework for the following components: o DPCS-R2R: Retrieves script and model data from PCS system, provides recommended settings, and displays results to users to get inputs o DPCS-FDC: Monitors equipment during process in real time to determine if the tool is operating within the desired specifications, and trigger actions to abort current processing or stop equipment if out of control/specifications condition is detected o DPCS-SPC: Provides the SPC functionality for collected data. For example, summary data from the DPCS-FDC system can be trended over time using DPCS-SPC • PCS Executor: Receives calls, generates a JobID for every incoming request. The JobID must be unique on a given machine. Also, it determines which component (R2R, FDC, SPC, CFG) to call. Finally, it invokes the appropriate method • PCS Framework (PCS Shared Components): Provides common components and services to the R2R, FDC and SPC applications. For example, the following components can be part of PCS framework o Computational engines o Charting of data o Reaction by putting unit on hold, shutting equipment down, sending warning messages through email and/or paging. o Security through managing user privileges for using systems o Logger, where Log messages (fatal, error, warning, info, debug). • PCS-R2R: Receives measurements and store them in its database. Then, it provides recommended settings, or script and model data for DPCS R2R for wafer level control • PCS-FDC: Stores summary or error data on a lot basis and invokes SPC to trend FDC summary data and triggers actions if needed

7

7. INDUSTRY DIRECTION: PROCESS CONTROL SYSTEMS SEMI STANDARDS Achieving the PCS integration goals will require conformance to industry interface standards. Open, standardized interfaces are required to avoid custom solutions, which increase implementation time with an added cost to both the IC manufacturer and the supplier. PCS standards [3], [11], [12] will be required to support agile manufacturing and process control initiatives. These standards (if adopted) will allow Integrated Circuit makers and suppliers to focus on improved capabilities rather than customized integration, and decreasing the risk introduced with integrating new applications into an existing factory. This section will address Intel external engagement to develop the PCS standards that facilitate PCS integration. 7.1 PCS SEMI Task Force: In order to more efficiently facilitate the integration of PCS implementations into current and future Fabs, Intel lead the development of the interfaces for Process Control Systems that enable them to interact effectively and share data among themselves and with the other interdependent factory systems (including equipment data collection). Intel took the initiative and proposed the formation of the Process Control Systems SEMI TF (PCS SEMI TF) which was kicked off in January 2002. The PCS SEMI TF was chartered “to define inline PCS architecture interfaces for run-to-run (R2R), fault detection and classification (FDC) and statistical process control (SPC) capabilities.” The first deliverable currently being finalized by the task force is the PCS Standards balloted under SEMI Document number 3527, entitled “New Standards- Provisional Specification for Automated Process Control Systems Interface.” The ballot will be submitted for voting at the SEMI Standards meeting, SEMICON west, July 2003. The benefits of such a standard would be reduced systems integration time and cost, and an acceleration of industry adoption of PCS technology. Manufacturing software suppliers (commercial or in-house) would use these standards to implement well-defined external interfaces to their process control applications. This will enable customers to integrate these systems more cost–effectively with one another and with other software systems required by the wafer fabrication process. The following sub-section summarizes the scope of the standards. 7.2 Scope of the PCS Standards: The PCS standards focus on defining PCS capabilities, functional groups, and functional group interfaces. By definition [3], a Functional Group (FG) is a “collection of closely related software capabilities that one would expect to be provided as an integrated product.” Based on this definition, and according to the priorities of the semiconductor manufacturers and suppliers involved with the PCS SEMI TF, the PCS functional groups initial list included: • R2R (Run-to-Run) Control • FD (Fault Detection) • FC (Fault Classification) • FP (Fault Prediction) • SPC (Statistical Process Control) It should be noted that Fault Prediction (FP) FG was added to this list since it is expected to be a future FG. From this list, it is clear that each PCS implementation/application discussed in this paper can be considered as a FG. The PCS standards ballot tarts by defining key terms, concepts and terminology pertinent to the PCS domain. The ballot then details the required capabilities for each FG. It addresses both required (must have) and optional (should have) requirements. The PCS Analysis Engine concept is introduced and its interfaces are detailed. These interfaces include defining data available across the interfaces (inputs and outputs), common model for all PCS FG’s (inheritance and aggregation models) and services supported and interface behavior model.

8

The specific format and protocol implementation of these interface specifications, which are technology specific, will be delineated in supporting “dot” specifications to the PCS standard. As an example a possible format is XML (which would include data type definitions and metamodel schemas). The PCS standards are structured so that new functional groups can be added through future balloting. The PCS TF owned the disposition of E93 (the APC Framework standard). The TF has surveyed the industry to understand the current usage of E93 by users and suppliers of process control systems, and made a recommendation to “sunset” this standard immediately due to its limitations [10], [11].

7. Conclusions With the introduction of silicon nanotechnology, feature sizes are shrinking and as a result, smaller variations will adversely affect product quality, yield and cost. Aimed at minimizing variability, PCS implementations/application need to be tightly coupled, functionally cascaded, architecturally streamlined and fully integrated to achieve the desired levels of process control. PCS integration will result in data, analysis, architectural components sharing, commonalities leveraging, and ease of integration to external and internal systems in addition to the reduction of redundant implementations and support efforts. Intel integrated PCS architecture was designed to achieve these goals. Its topology and characteristics were discussed in this paper along with its components. To facilitate integration, Intel is driving (through the PCS SEMI TF) the PCS architectural interfaces.

Acknowledgement The authors would like to thank Dr. Guozhong Zhuang for his help in preparing this paper. Also, we would like to thank Intel PCS Architecture definition team who supplied us with supporting material.

REFERENCES [1] Douglas C. Montgomery, Introduction to Statistical Quality Control. 4th edition, John Wiley & Sons, Inc. 2001 [2] E. R. Ott, Process Quality Control, McGraw-Hill, New York, 1975 [3] SEMI Draft Document #3527: New Standards- Provisional Specification for Automated Process Control Systems Interface [4] G. B. Wetherill and D. W. Brown, Statistical Process Control: Theory and Practice. Chapman and Hall, New York, 1991 [5] Del Castillo, Enrique and Arnon M. Hurwitz, "Run-to-Run Process Control: Literature Review and Extensions," Journal of Quality Technology, vol.29, no. 2, p. 184-196, April 1997 [6] John S Baras, and Nital S. Patel, "A Framework for Robust Run by Run Control with Lot Delayed Measurements," IEEE Transactions on Semiconductor Manufacturing, vol 10, no. 1, February 1997 [7] Youssry Botros, Process Control System Requirements, Intel Document [8] Youssry Botros, Alex Cameron, Ray Inocencio, Ravi Khairate, Lisa Pivin, Krishna-Prasad Srirama, and Shaopeng Wang, Process Control Systems Use Cases, Intel Document [9] Intel PCS Architecture Definition Team, Process Control Systems: Architecture Design Document, Intel Document [10] SEMI E93 – Provisional Specification for CIM Framework Advanced Process Control Component [11] SEMI Draft Document # 3634, Withdrawal of SEMI E93 – Provisional Specification for CIM Framework Advanced Process Control Component [12] Youssry Botros, Alan Weber and James Moyne, “Specification for Integrated Process Control: An Emerging SEMI Standard from the Process Control Systems (PCS) Task Force to Enable PCS Component Integration,” The Advanced Equipment Control/Advanced Process Control, Utah, September 2002 [13] Youssry Botros, Guozhong Zhuang, and Krishna-Prasad Srirama, “Integrated Process Control Systems: Benefits, Requirements, and Architecture,” The Advanced Equipment Control/Advanced Process Control, France, March 2003 [14] International Technology Roadmap for Semiconductors, Factory Integration and Control System, 2002 Edition

9