Implementing fabwide process control systems with Interface-B APC solutions
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 item—component integration—has
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
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.