RequestLink
MICRO
Advertiser and
Product
Information

Buyer's Guide
Buyers Guide

tom
Chip Shots blog

Greatest Hits of 2005
Greatest Hits of 2005

Featured Series
Featured Series


Web Sightings

Media Kit

Comments? Suggestions? Send us your feedback.

 

MicroMagazine.com

E-Manufacturing:

Implementing fabwide process control systems with Interface-B APC solutions

Anyone working on standards, especially those breaking new ground, is enmeshed in the fine details of many of the semiconductor industry's burning issues on a regular basis. Instead of the usual "panel in print" format, this issue's Hot Button features the collective viewpoint of some of the key people working on a SEMI standard that could have a significant impact on the automation and advanced process control strategies being implemented in today‚s state-of-the-art fabrication facilities.

JAMES MOYNE (director of APC technology, Brooks Software); PETE KLIMECKY (senior automation engineer, Intel); and RUSS LEWANDOWSKI (president, Buffalo Automation): Advanced process control (APC) has evolved in the span of 10 years from a research project to a fab requirement. Process control systems (PCS) that implement these capabilities provide essential benefits at the process, photomask, and fab levels. Benefits at the process level include reduced nonproduct wafers and scrap, improved process capability, and reduced cost of consumables, while at the fab level PCS can optimize yield, throughput, and electrical characteristics.

While the benefits are significant, adoption has been relatively slow. APC science is a relatively new field, so it generally doesn't mesh with the expertise of fab personnel. The cost of technology integration can be prohibitive, and true adoption at a fab level requires full integration with other fab functions. The last itemcomponent integrationhas been identified as a primary area of focus inhibiting the proliferation of PCS in the fab because of a lack of common interface models. SEMI has refined the problem by identifying an "Interface B," which is the interface between PCS applications and among PCS and non-PCS applications. The lack of standard interoperability and plug-and-play specifications for this interface has impeded the widespread adoption of PCS capabilities.

In an ongoing three-year effort, the SEMI PCS task force has addressed this integration and interoperability problem by developing "E133: Provisional Specification for Automated Process Control Systems Interface." E133 facilitates the integration of PCS into current and future fabs. The standard defines capabilities of five PCS functional groups: run-to-run (R2R) control, fault detection (FD), fault classification (FC), fault prediction (FP), and statistical process control (SPC). The standard also specifies PCS interfaces and an interface data model that will enable these functional groups to interact effectively and share data among themselves and with the other interdependent factory systems, including process tool subsystems.

E133 facilitates the integration of PCS into current and future fabs.
—James Moyne et al.

An enhanced version of the standard includes behavioral models to support a number of use cases common in fab implementations and additional specification requirements for the R2R control, FD, and SPC groups. Also, an E133.1 companion standard under review defines the specification of PCS messaging requirements in XML.

The E133 effort is truly an international effort, with participation from user companies and various parts of the supplier community. The task force, cochaired by representatives from Intel and Brooks Automation, includes representatives from AMD, TSMC, and IBM, as well as from TEL and other leading OEMs. Companion groups in Europe and Taiwan are also collaborating with the North American task force.

As an example of how to utilize the PCS standard, consider a CMP application: R2R control is deployed to maintain quality levels with respect to film thickness (to target) and uniformity, and FD is used to determine when the tool is healthy and to predict when product scrap may occur as well as when a tool should be brought down for maintenance ahead of the occurrence of scrap generation. The PCS standard first comes into play by guaranteeing a level of capability of R2R control and FD applications. For example, the capability of the R2R control application to support feedback and feedforward data falls under the scope of PCS.

Next, the standard specifies the structure of the messages that the R2R control and FD engines produce and consume. For example, all transactions are associated with a unique PCS JobID. Data in all messages into the engines are separated into bins, such as SubstrateData and CalculatedOutputs, and each datum is assigned a role of "Context" or "Data." If the communication mechanism is XML, E133.1 would define the format and requirements of each message so that the message context can be prevalidated.

By using the PCS standard, the minimum capabilities of the R2R control and FD engines are guaranteed, additional capabilities of those engines are succinctly reported, and a common standard interface to these engines can be set up. In addition, standard interfaces between the R2R control and FD, as well as between these engines and non-PCS capabilities such as maintenance management, can be specified in a standard interoperable manner.

The PCS standard is important not only because it defines the capabilities and interface specifications that will facilitate integration and interoperability of PCS components with other PCS and non-PCS components, but also because it suggests a mechanism for fabwide deployment of process control solutions that contain multiple PCS components. Fabwide control systems can become very complex very quickly, especially when interaction with non-PCS components must be addressed. This problem can become exacerbated, since APC capabilities are often implemented incrementally and thus the control strategies defining interaction of components must also be (re)configured incrementally. Traditional control approaches at the fab level, such as hard coding and scripting, are often not cost-effective in these situations. While the PCS standard by design does not specify implementation approaches, the PCS task force, in various publications and tutorials, has provided insight into this problem and has shown how graphical-event-based systems can be used to more efficiently implement E133-compliant PCS strategies.

With the functional group input/output messaging structure and input/output behavioral models well defined, and with XML specifications for PCS messaging and message validation being put in place, E133 has matured. It should now be consulted in fabwide PCS implementations so that a degree of PCS component interoperability and interchangeability can be achieved.

In addition to developing and maintaining the standard, the PCS task force has focused on providing tutorials and presentations that describe best practices for implementing PCS systems fabwide. (To access these materials, go to www.aecapcsymposium.org.) E133 and the supporting information should be viewed as the final step that will allow users, OEMs, and other suppliers to get together and implement fabwide PCS in a cost-effective manner, so that these systems can become fully integrated into the fab infrastructure as an essential and required part of plant operations.


MicroHome | Search | Current Issue | MicroArchives
Buyers Guide | Media Kit

Questions/comments about MICRO Magazine? E-mail us at cheynman@gmail.com.

© 2007 Tom Cheyney
All rights reserved.