Control Systems Requirements Specification (CSRS) 2 · · 2000-02-29Control Systems Requirements Specification (CSRS) 2.0 ... Advanced Process Control, CIM, Control Systems, Standards

SEMATECHTechnology Transfer 96123222B-ENG

Control Systems RequirementsSpecification (CSRS) 2.0

© 1998 SEMATECH, Inc.

SEMATECH and the SEMATECH logo are registered service marks of SEMATECH, Inc.

Product names and company names used in this publication are for identification purposes only and may be trademarks or servicemarks of their respective companies

Control Systems Requirements Specification (CSRS) 2.0Technology Transfer # 96123222B-ENG

SEMATECHFebruary 27, 1998

Abstract: This document updates a Control Systems Requirements Specification (CSRS) developed bySEMATECH’s Control Systems Standardization Working Group (CSSWG) in cooperation withSEMI’s Equipment Control Systems Task Force (ECS-TF). The main purpose of the document isto provide a requirements specification that will specify in a common and reusable way theaddition, deletion, or modification of sensors, algorithms, applications, and control capabilities insemiconductor processing systems at the user skill level. In achieving this objective, the documentmaps requirements specifications to a set of existing, pending, and future SEMI standards toprovide an umbrella-like directory for a complete CSRS. Additionally, the document contains aspecification for adding control capabilities to current and near-term next-generation systems thatincludes a migration path to the CSRS.

Keywords: Advanced Process Control, CIM, Control Systems, Standards

Authors: James Moyne

Approvals: Joe White, Project ManagerDan McGowan, Technical Information Transfer Team Leader

Technology Transfer # 96123222B-ENG SEMATECH

iii

Table of Contents

1 EXECUTIVE SUMMARY....................................................................................................... 71.1 Summary of Revisions to Version 1.0 .............................................................................. 71.2 Description of the CSRS................................................................................................... 8

2 INTRODUCTION................................................................................................................... 102.1 Acronyms........................................................................................................................ 11

3 THE CSRS VISION................................................................................................................ 123.1 Using the CSRS .............................................................................................................. 12

3.1.1 Example #1: Adding a Control Capability to an Existing System....................... 123.1.2 Example #2: Purchasing a Next-Generation Tool ............................................... 13

4 BACKGROUND..................................................................................................................... 144.1 Guidelines for CSRS Construction and Update.............................................................. 14

5 CONTROL SYSTEMS REQUIREMENTS SPECIFICATION............................................. 155.1 Summary of Revisions Over CSRS Version 1.0 ............................................................ 155.2 Control Systems Requirements Specification (CSRS), Version 2.0............................... 165.3 Control Domain .............................................................................................................. 185.4 Reliability Domain.......................................................................................................... 215.5 Support Standards ........................................................................................................... 22

6 A CSRS FOR CURRENT AND NEAR-TERM NEXT-GENERATION SYSTEMS........... 236.1 Introduction and Motivation ........................................................................................... 236.2 Issues............................................................................................................................... 246.3 A CSRS for Current and Near-Term Next-generation Systems ..................................... 25

7 CONCLUSIONS..................................................................................................................... 277.1 Control Systems Requirements Specification References and Status ............................ 287.2 The Equipment Control Systems Task Force and CSRS Support .................................. 307.3 Towards a Complete CSRS: Contributions of the ECS-TF............................................ 30

7.3.1 Very High Priority Activities............................................................................... 307.3.2 High Priority Activities........................................................................................ 317.3.3 Medium Priority Activities .................................................................................. 31

8 SUMMARY ............................................................................................................................ 31

9 REFERENCES........................................................................................................................ 32

APPENDIX A ............................................................................................................................... 33

APPENDIX B................................................................................................................................ 37

APPENDIX C ............................................................................................................................... 50

APPENDIX D ............................................................................................................................... 52

APPENDIX E................................................................................................................................ 55

APPENDIX F................................................................................................................................ 57

APPENDIX G ............................................................................................................................... 61

SEMATECH Technology Transfer # 96123222B-ENG

iv

List of Figures

Figure 1 Process for Identifying “Holes” in the CSRS to Develop a More CompleteSpecification............................................................................................................... 15

Figure 2 Specifications in the Control Domain........................................................................ 18

Figure 3 CSRS for Current and Near-Term, Next-Generation Systems .................................. 27

Figure 4 The SEMI Equipment Automation and Control Standards Timeline ........................ 38

Figure 5 Logical View of the Semiconductor Factory Control System.................................... 39

Figure 6 The APC Framework Integrated In the CIM Framework.......................................... 56

Figure 7 The APC Framework Advanced Process Controller ................................................. 56

Figure 8 Example of Piggyback Controller Implementation: (Real-time ControlPiggyback Controller for a Process Control Module in a Cluster Tool).................... 58

Figure 9 Illustration of CSRS for Piggyback “Pass-Through” Operation................................ 60

Figure 10 Migration of the Piggyback Control Capability......................................................... 60


v

List of Tables

Table 1 Control Systems Requirements Issues ....................................................................... 17

Table 2 Analysis of Standards for Current and Near-Term, Next-Generation,CSRS-Compliant Systems ......................................................................................... 24

Table 3 A CSRS for Current and Near-Term, Next-Generation Systems............................... 26

Table 4 ECS-TF Cochairs ....................................................................................................... 30

Table 5 Roadmap: Equipment Control Level ......................................................................... 40

Table 6 Roadmap: Interface Between Equipment and Run-to-Run Control Levels ............... 42

Table 7 Roadmap: Run-to-Run Control Level........................................................................ 43

Table 8 Roadmap: Interface Between Run-to-Run and Factory Control Levels..................... 44

Table 9 Roadmap: Factory Control Level............................................................................... 45

Table 10 A Mapping of Control Systems Requirements Issues into Current andPending SEMI Standards and SEMATECH Specifications ...................................... 46


vi

Acknowledgements

The authors gratefully acknowledge the contributions of CSSWG members in the developmentand refinement of the control systems requirements specifications. Additional thanks are due tocoauthor Joe White for guiding the project and the CSSWG; coauthor John Pace for his directionin upgrading the specification and facilitating its transfer to the ECS-TF; Dale Blackwell ofSEMATECH for his critical review of all versions of the document; Margaret Pratt ofSEMATECH for providing valuable insight into OBEM activities; Joe Abuan of SEMI forsupplying a wealth of information on SEMI standards activities; and SEMATECH in general forsupporting this effort. The authors also gratefully acknowledge ECS-TF members for providing asmooth transition of this effort from SEMATECH to SEMI, and look forward to working withinthe ECS-TF to develop an effective and complete CSRS.


7

1 EXECUTIVE SUMMARY

This document is Version 2.0 of a Control Systems Requirements Specification (CSRS) forsemiconductor processing equipment applications. The main purpose of the document is toprovide a requirements specification that will specify in a common and reusable way thefunctional capabilities to allow addition, deletion, or modification of sensors, algorithms,applications and control capabilities in semiconductor processing systems at the user skill level(i.e., without requiring the aid of an original equipment manufacturer (OEM) or integratorsoftware engineers). To achieve this objective, the document maps requirements specifications toa set of existing, pending, and future SEMI standards thus providing an umbrella-like directoryfor a complete equipment control system CSRS. The requirements were derived from a set of“raw” requirements researched by the CSSWG. The CSRS is the major contribution of theControl Systems Standardization Working Group (CSSWG) of SEMATECH.

This document includes input from the following:

1. Existing and pending SEMI standards

2. SEMASPECS and other specifications

3. Data from Advanced Equipment Controller (AEC) Preliminary Requirements and FunctionalCapabilities Version 1.0, Technology Transfer #95123035A–TR

4. CSSWG Requirements

This specification was written according to the following guidelines:

1. Specify the state-of-the-art in control and communication capabilities and, wherever possible,a migration path from any obsolete but widely used technology.

2. Specify a complete solution (i.e., address all equipment control systems requirements withstandard specifications) and identify “holes” where (future) SEMI standardization is needed.

3. Be simple and concise, providing an “umbrella” document that dictates the form of acomplete specification, and that references specification components rather than providingintrinsic detail. As such, this document is not intended to be offered initially as aSEMASPEC or as a proposed standard for SEMI balloting. Elements of the document areintended to drive future work toward SEMASPECs or SEMI standards in specific functionalrequirement areas.

1.1 Summary of Revisions to Version 1.0

This document supplements version 1.0, which was published in December 1996. In thisrevision, the following major components have been added:

1. A CSRS vision section has been added to better motivate the CSRS and explain its use.

2. A section called “CSRS for current and near-term next-generation systems” has been addeddescribing a CSRS that utilizes existing standards and specifications and is aligned with theInternational 300 mm Initiative (I300I).

3. The appendix that addresses Advance Process Control (APC) Framework alignment has beenexpanded to reflect alignment with significant results achieved by the APC factoryintegration working group during 1997.

4. The appendix that addresses 300 mm requirements has been expanded to address I300Ialignment.


8

5. The appendix containing the piggyback controller description has been expandedsignificantly and now includes an example of development of a piggyback run-to-runcontroller utilizing the CSRS.

6. An appendix has been added that maps CSSWG raw requirements to Table 1 in the CSRSbody.

7. The document has been updated throughout to capture advances at SEMI, APC,SEMATECH, etc.

8. The document has been updated to reflect the activity and the pending transfer of thisdocument to the SEMI Equipment Control Systems Task Force (ECS-TF).

Version 2.0 of the document has been developed with the cooperation and technical assistance ofthe SEMI Equipment Control Systems Task Force (ECS-TF). The charter of this task force is tostudy the CSRS, identify the subset of requirements for which there are no existing or pendingSEMI standards, and facilitate the development of standards or guidelines for these requirements.It is expected that future revisions of this document will be developed and managed by SEMIunder the direction of the ECS-TF.

1.2 Description of the CSRS

The CSRS is divided into control and reliability components. The control component specifiesthe following standards and specifications (existing, pending, or envisioned):

• Sensor/Actuator Network (SAN) Standard (existing). This suite of standards definesconcepts, behavior and message services to facilitate device level communications over aSensor/Actuator Bus, thereby integrating sensors and actuators into the equipment controlsystem.

• Object Based Equipment Model (OBEM) Standard (pending). This suite of standards definesconcepts behavior and message services to realize equipment control systems. The OBEMstandard defines the operation of the equipment controller including utilization of SANcompliant device level systems, and visibility to higher level control systems.

• Generic Equipment Model (GEM) Standard (existing). This standard defines the genericbehavior of semiconductor equipment as viewed through a communications link in terms ofSECS-II messages. GEM is specified as a component of current and near term next-generation solutions. Migration to OBEM from GEM is specified in the long-term CSRS.

• Computer Integrated Manufacturing (CIM) Application Framework (existing, butnon-SEMI): This specification creates a common environment for integrating applicationsand sharing information in a CIM factory domain. The CIM standard, which includes theAPC Framework for control, defines the operation of the factory CIM system, includinglinkage to OBEM compliant systems. Framework components are being converted to SEMIstandards ballots.

• Wafer Traceability Standard (pending): This standard addresses the traceability of materialsand other factory resources in the facility.

Note that these specifications address control and communication conformance at all controllevels of the semiconductor factory, from wafer level issues up through equipment control tofactory control.


9

The reliability component of the CSRS specifies the following standards and specifications:

• Automated Reliability, Availability and Maintainability Standard (ARAMS) (existing). Thisstandard defines concepts, behavior and message services to facilitate equipment levelcapture and communication of equipment reliability, availability, and maintainabilityinformation.

• Equipment Maintenance Standard (EMS) (envisioned). This standard defines metrics andgeneric procedures for equipment maintenance and includes both scheduled and unscheduledmaintenance.

• Control System Performance Specification Standard (CSPS) (envisioned). This standarddefines metrics and methods for parameterizing the performance of control systems in termsof response time, determinism, bandwidth, etc.

• Testability Requirements Specification (TRS) (envisioned). This standard defines parametersthat describe and facilitate the testability of control systems with respect to conformance toother requirements specifications.

A review of the CSRS elements indicates that 1) the requirements list is incomplete and 2) manyof the needed standards specifications require further development. Continuation of therequirements gathering process, and contributions to the development and direction ofappropriate SEMI standards efforts, should be the focus of future efforts (e.g., of the ECS-TF).

A major drawback of the CSRS when viewed in its entirety is that the full CSRS cannot yet berealized since many of its components are not completed SEMI standards or specifications. Inorder to make the CSRS more usable in today’s systems, a CSRS for current and near-term next-generation systems is included in the document. The systems to which this CSRS applies includeexisting systems (to which the CSRS could be applied to the retrofitting of APC), and systems tobe purchased in 1998, including I300I-compliant systems. As with the long-term CSRS vision,the CSRS for current and near-term next-generation systems provides a partial requirementsspecification using existing standards that specifies in a common and re-usable way the addition,deletion, or modification of sensors, algorithms, applications and control capabilities insemiconductor processing systems at the user skill level.

This CSRS is considered a partial solution, because the standard (plus additional not-yet-standardspecifications) set does not yet exist to specify a complete CSRS. A migration path to futureCSRS systems also is provided to maintain alignment with the envisioned CSRS. An appendixdefines in more detail the impact of these specifications on existing (e.g., retrofitting), near-future(e.g., piggyback control extensions), and immediate next-generation systems. Additionally, thedocument details the migration from this current near-term next-generation solution to theenvisioned CSRS. This migration is proposed as part of the effort of the ECS-TF.

In order to provide a foundation for discussion, description, and evolution of the CSRS, severaldefinitions are used. These include run-to-run control, piggyback controller, real-time monitoringand control, in situ control, interprocess control, etc. These definitions have been derivedwherever possible from relevant literature and discussions with CSSWG members. However,because these definitions often represent concepts that are not yet fully developed, the definitionsthemselves may evolve in later versions of the CSRS.

The CSRS will continue to be aligned with three significant parallel efforts: the APCFramework, 300 mm ECS requirements, and I300I activities. All three efforts are focused on the


10

specification of next-generation control systems and have generated significant results in 1997.The CSRS is compatible with the directions of each activity and will support as much as possiblethe control structures proposed by these activities.

It is important to note in conclusion that the CSRS is expected to continue to evolve significantlyunder the guidance of the SEMI ECS-TF. Thus, this specification is preliminary and contains amixture of firm requirements as well as recommendations for additional development. As part ofthe CSRS evolution, elements will be added to the specification as necessary to address any newrequirements that are identified through interviews with users, OEMs, control systems suppliers,integrators, standards leaders, and ECS-TF members. Throughout this evolutionary process, thebasic guidelines listed above are expected to be followed to ensure that the CSRS documentremains as a high-level umbrella document that is simple, concise and effective.

2 INTRODUCTION

Realizing the importance of and need for a CSRS for the semiconductor industry, the CSSWGdefined a project whose primary objective is “to deliver a standard set of requirements forequipment control systems for semiconductor process equipment applications.” The resultingCSRS in turn will provide a document that will specify in a common and reusable way theaddition, deletion, or modification of sensors, algorithms, applications and control capabilities insemiconductor processing systems at the user skill level. This effort will provide a number ofbenefits to the industry, including the following:

1. A user/supplier purchase specification

2. Reduction in the need for user custom software

3. Reduced equipment variability from single or multiple suppliers

4. Encouraging of manufacturers to “speak with one voice”

5. A basis to impact control system reliability

6. A path to improved process capability [8]

In providing the CSRS, this specification is organized as follows:

Section 3 provides a vision of the utility of a CSRS for current and next-generation systems andincludes examples of the use of the CSRS in defining purchase specifications.

Section 4 provides background information and guidelines for constructing a specification thatshould be used to generate future revisions.

Section 5 presents the specification itself and includes a review of enhancements andmodifications from the most recent version of the specification.

Section 6 presents a CSRS for current and near-term, next-generation systems and includes amigration path to the envisioned complete specification given in Section 5.

Section 7 contains conclusions that include a prioritized list of areas in the specification thatreference incomplete or planned standards or guides. It is expected that SEMI standardizationwill be pursued in these areas, thus leading to a more complete CSRS. Section 7 also describesthe impending transfer of the CSRS to SEMI and the role of the ECS-TF.

Section 8 contains a brief summary and a list of relevant references.


11

Also included are seven appendixes that provide the following:

1. SEMI standard glossary

2. A control standards roadmap that details the derivation of the role of current and pendingSEMI standards and SEMATECH specifications in the CSRS

3. A glossary of specification terms

4. Discussion of the linkages of the CSRS to the SEMATECH 300 mm ECS and I300I activities

5. Discussion of the linkages of the CSRS to the APC Framework activities.

6. Discussion on using the CSRS in the specification of control systems in various current andnext-generation control environments

7. A mapping of the “raw” CSSWG researched requirements to the requirement set utilized inthis document (listed in Table 1)

2.1 Acronyms

Acronyms used in this document include the following:

AEC Advanced Equipment ControlAPC Advanced Process ControlARAMS Automated Reliability, Availability, and Maintainability StandardBOSS Book of SEMI StandardsCDM Common Device Model (sensor bus)CIM Computer Integrated ManufacturingCORBA Common Object Request Brokerage ArchitectureCSRS Control Systems Requirements SpecificationCSSWG Control Systems Standardization Working GroupCTMC Cluster Tool Module communications (Standard)ECS Equipment Control SystemEM Exception Management (Standard)GEM Generic Equipment ModelGUI Graphical User InterfaceHSMS High-Speed SECS Message Services (Standard)I300I International 300 mm InitiativeMES Manufacturing Execution SystemMESC Modular Equipment Sub-CommitteeMMI Man-Machine InterfaceMMM Material Movement Management (Standard)NCS Network Communication StandardOBEM Object Based Equipment Model (Task Force)OEM Original Equipment ManufacturerOSS Object Services StandardPM Process Management (Standard)RMS Recipe Management StandardSAN Sensor/Actuator Network (Standard)SDM Specific Device ModelSECS SEMI Equipment Communication Standard (Parts I and II)SEED Specification for Electronic Document Interchange


12

SEMI Semiconductor Equipment and Materials InternationalTCP/IP Transmission Control Protocol/Internet ProtocolUI User Interface

3 THE CSRS VISION

The CSSWG was established in early 1996 to pursue the specification of control systemsrequirements for the industry. In researching these requirements through interviews of users,integrators, OEMs, standards leaders, and CSSWG members, it became clear that thespecification of methods and components for adding a new control capability into a controlsystem is a fundamental requirement that should be addressed in a CSRS. Specifically, users,working with integrators and OEMs, would like the flexibility to easily and reliably add, delete,or modify a sensor, algorithm, application or control capability in an equipment control system.In further identifying this capability, the following guidelines were identified:

1. The specification should be defined so that the capability could be understood and added atthe user skill level, i.e., a skill level that does not require technical intervention of the OEMor third part integrator.

2. The specification should address current-generation and next-generation systems. It shouldprovide a migration path so that current solutions could be reused to a large extent innext-generation, CSRS-compliant systems.

3. The specification should reference SEMI standards wherever possible and should be alignedwith SEMI directions in standardization.

4. The specification should be aligned with current efforts in advanced control systemsspecification such as APC Framework and I300I.

3.1 Using the CSRS

The two primary components of the CSRS are 1) a specification for the enhancement of existingequipment control systems, and 2) a specification of future control systems. Users, integratorsand OEMs should utilize the first component when they wish to add a control capability (sensor,algorithm, application, etc.) to an existing system. The CSRS indicates the standards andspecifications to which the sensor supplier, OEM and integrator should adhere so that capabilitycan be easily added to the system. The second component should be utilized as an aid forenvisioning future equipment control systems and thus could be a component of a futureequipment purchase specification.

3.1.1 Example #1: Adding a Control Capability to an Existing System

As an example of the use of the CSRS in expanding the capabilities of an existing controlsystem, suppose that company “M” develops a metrology capability that reports a quality metricfor a process at user company “U.” Working with a control systems supplier, “C,” a relationshipbetween the process quality metric and the input recipe of a tool manufactured by supplier “T” isestablished. A need is identified to integrate the new metrology and control capabilities and


13

“close the loop” around tool “T” using run-to-run control1. Assuming the user company isorganizing this effort, it would look to Section 6 and Appendix F of this document. Reviewingthese sections, the user would obtain the following:

1. A general description of how run-to-run control is implemented in CSRS compliant systems

2. An understanding of the GEM capabilities of the tool that could be utilized to “close theloop”

3. Input for a specification that could be provided to “M” to ensure that the appropriatemetrology information could be obtained from the metrology tool

4. Input for a specification that could be provided to “T” to ensure that the tool has theflexibility to accept recipe “advices” generated by the control solution

5. Input for a purchase specification that could be provided to “C” that will result in a controlsolution that easily accommodates the metrology system and tool, provides closed loop run-to-run control, and can be migrated to next-generation solutions

6. Input for a suite of specifications that could be provided to the integrator to facilitate rapiddevelopment of communications with the metrology system, tool, and factory system

3.1.2 Example #2: Purchasing a Next-Generation Tool

As an example of the use of the CSRS in specifying a future control system, suppose that User“U” wishes to purchase a next-generation tool in the near future from tool supplier “T.” The userwould like the tool to implement state-of-the-art advanced process control, but also would likethe tool to provide mechanisms understandable by a user for implementing additional control.The User would utilize the entire CSRS (especially Section 6) and obtain the following:

1. A general description of the state-of-the art in advanced process control and associatedstandardization

2. A listing of control systems requirements that should be considered when purchasing the tooland a discussion of the capability of the user to specify these requirements through adherenceto SEMI standards and specifications

3. Input for a purchase specification that will help to ensure the following:

− Control systems requirements are met.− Control systems requirements are accessible to and usable by a user/integrator.− The control system is compatible with compliant sensors, algorithms, and

applications.− The control system solution is on a migration path to a fully compliant CSRS

system.

4. A migration path that will allow the user to migrate control solutions on existing systems tothe new tool

1 Run-to-run control is a form of discrete process control in which process quality measurements are utilized to improve future process “runs”

by suggesting process recipe adjustments.


14

4 BACKGROUND

4.1 Guidelines for CSRS Construction and Update

This report is the first major revision of a CSRS for semiconductor processing equipmentapplications that is being designed to become a SEMI equipment control systems specification.The CSSWG and ECS-TF will continue to enhance and update this document as necessary tocapture results and directions of related activities in SEMI and SEMATECH. As this documentevolves, pitfalls such as lack of focus/direction and unnecessary complication must be avoided.In an attempt to avoid these pitfalls, the following document construction and evolutionguidelines are proposed:

1. Input for the CSRS will be derived from the following sources with the guidelines listedbelow:

• Existing and pending SEMI standards (reuse): An the early conclusion of theCSSWG in deciding the basic content of the CSRS is that the specification shouldutilize as much as possible existing and pending SEMI standards as a foundation[3, 4, 8, 9]. A study of the potential role of these standards and pertinentSEMATECH specifications was conducted and a Control Standards Roadmapderived [4, 6]. The results of this study are included in Appendixes A and B.

• AEC Preliminary Requirements and Functional Capabilities (reuse): A previousAEC effort has generated a preliminary list of control system requirements andcapabilities. These results should represent a component of the foundation of thisreport [10].

• CSSWG Requirements: The CSSWG has conducted a roundtable requirementsgathering session. These requirements, which are summarized in Appendix G,should continue to be addressed in the CSRS [7].

• Feedback: The CSSWG and ECS-TF will solicit feedback continuously on theCSRS as it evolves. Feedback should be solicited frequently from working groupand task force members, as well as users, OEMs, control system suppliers, SEMIequipment control standards leaders, etc., and should be incorporated into theCSRS as much as possible.

• Advanced Process Control (APC) and 300 mm Equipment Control Systems(ECS) and I300I efforts: These efforts are producing results relevant to the CSRS.As the CSRS evolves, it should continue to be compatible with control systemsspecifications forwarded by these efforts.

2. All specifications should specify the state-of-the-art in control and communicationcapabilities. Standards or specifications that are (or soon will become) obsolete should not beincluded in the CSRS. However, wherever possible, and especially in the cases of a largeimplementation base, a migration path should be provided from current technology to theCSRS solution.


15

3. The CSRS should specify a complete solution. “Holes” in the specification should beidentified and later versions of the specification should attempt to fill these holes with futureSEMI standard or other specifications (see Figure 1).2

4. The CSRS should be an “umbrella” document that dictates the form of a completespecification, but points to (i.e., references) the components of this specification rather thandetailing the specifications intrinsically. Thus, a complete CSRS necessarily includes thestandards referenced in this CSRS.

5. The CSRS should strive to be simple and readable. Details and derivations should not be inthe main body of the document (they could referenced or included as appendixes).

Control Syst. Req.Spec. (Vers. ‘n’)

Identificationof AdditionalWork Needed

WorkEfforts

SEMIFeedBack

from CSSWG

Control Syst. Req.Spec. (Vers. ‘n + 1’)

Figure 1 Process for Identifying “Holes” in the CSRS to Develop a More CompleteSpecification

5 CONTROL SYSTEMS REQUIREMENTS SPECIFICATION

5.1 Summary of Revisions Over CSRS Version 1.0

Comments from the CSRS and ECS-TF on Version 1.0 and the Version 2.0 roadmap [2] have ledto the following enhancements and changes to this version:

• Section 3, “The CSRS Vision”, has been added to provide a more detailed description of theutility of the CSRS, especially as an aid in adding a control capability to a current orenvisioned system.

• Human interface domain requirements and corresponding requirements specifications havebeen removed from the specification as they have been deemed outside the scope of thedocument.

2 A “hole” in the specification is a CSRS requirement or group of requirements that are not addressed by any existing SEMI standards. These

requirements could be addressed with future standards, groups of standards, or enhancement of existing standards.


16

• The document has been aligned with the 1997 I300I effort [14]. This alignment issummarized in an expanded Appendix D.

• Section 6 has been added which is a CSRS for current and near term next-generation systemsand includes a migration path to the envisioned complete specification given in Section 5.Note that these systems include “piggyback” control systems enhancements (seeAppendix F).

• The Conclusions section has been expanded to include a description of the ECS-TF andpropose directions for the ECS-TF in moving towards a complete CSRS.

• Appendix E has been expanded to provide a more detailed description of the utilization of theCSRS in providing a run-to-run control capability.

• Appendix F has been expanded to describe alignment the APC Framework; this Frameworkhas matured significantly during 1997.

• Appendix G has been added that maps the “raw” requirements researched by the CSSWG tothe summarized list of requirements presented in Table 1.

5.2 Control Systems Requirements Specification (CSRS), Version 2.0

Table 1 lists many of the requirements that have been identified for control systems in thesemiconductor industry. The table specifies these requirements across a number of domains toensure interoperability in each. Specifically, the CSRS is divided into control and reliabilitydomains. The control domain specifies the structure and operation of the entire factory controlsystems. The reliability domain addresses issues such as equipment uptime, maintenance, etc.


17

Table 1 Control Systems Requirements Issues

Issue Domain

1. Specification for synchronization/time stamping of data Control

2. Real-time (in situ), run-to-run and factory level control capabilities Control

3. Specifications for combining run-to-run and in-situ control Control

4. Specifications for combining run-to-run and factory level control Control

5. Defining equipment, run-to-run, and factory level control systemsutilizing a standard object-based paradigm

Control

6. Specification for sensor integration into the control system (models,communication protocols, etc.)

Control

7. Specification for integration of (3rd party) control algorithms atequipment and run-to-run level (without affecting integrity of controlsystem or tool)

Control, Reliability

8. Defining data accessibility/visibility at equipment and run-to-runcontrol levels

Control

9. Specifications for remote monitoring Control

10. Specifying wafer state information Control

11. Supporting wafer driven processing Control

12. Specifications for volume data management Control

13. High speed network compliance Control

14. Defining a successor to SECS-II GEM that delivers higher throughput Control

15. Specifications defining visibility of machine operations Control, Reliability

16. Deterministic performance requirements Control, Reliability

17. Configuration management requirements Control, Reliability

18. Specifications for equipment transition between up/down time,maintenance, etc.

Reliability

19. Specifications for equipment maintenance Reliability

20. Specifications for testability requirements Reliability

21. Specifications for fault detection and end-point control Control, Reliability

22. Alignment with the APC Framework Efforts Control

23. Alignment with 300 mm ECS Efforts Control

24. Alignment with I300I Efforts Control

25. • • •


18

The following subsections identify control systems requirements specifications for each domain.A specification consists of the following:

1. A brief description

2. An identification of requirements addressed by that specification

3. References to appropriate documentation (current, pending, or envisioned) that details thespecification

4. An indication of the state of development of the specification details

Section 7 contains additional reference information on the status of nonexistent specifications(i.e., pending or envisioned) specifications and possible contributions of the CSSWG.

5.3 Control Domain

The basic specifications in the control domain specify the structure, behavior and interaction ofthe components of the hierarchical semiconductor facility control system. These specificationsand their interaction is illustrated in Figure 2. The following are the specific components of thecontrol domain specification.

Process Flow Management

Standardized High LevelProcess Flow Language

Object-BasedCommunications

Run-to-Run Controller

Equipment Controller

• Run-to-Run Process and Equip. Control • • Object Models •

• In-Situ Control Framework • • Object-Based Equipment Models •

• MESC (Cluster Tools) •• Device System Control •

Equipment

Sensor / Actuator Network

Sensor / Actuator Devices• Object-Based Device Models •

Factory Controller

Inter-Process Control(feed-forward and feedback)

Scheduling SEMATECHCIM Framework

OBEM

SAN (Sensor Bus Std.)

Control RequirementsSpecifiction

Object-Based Comm.

Product Flow

Traceability

SEMATECHAPC Framework

Control SystemsSpecification

Figure 2 Specifications in the Control Domain


19

• Sensor/Actuator Network (SAN) Standard: This suite of standards defines concepts, behaviorand message services to facilitate device level communications over a Sensor/Actuator Bus,thereby integrating sensors and actuators into the equipment control system. The SANstandard addresses requirements associated with device level systems and their integrationinto the equipment controller. Specifically at the equipment controller to equipment interfacelevel, requirements addressed by this standard include: sensor integration into control system,synchronization of data, network compliance, object-based solutions, data accessibility,integration of device control algorithms, and real-time in situ control.

#1 Specification Sensor/Actuator Network Standard

Requirements addressed (from Table 1) 1, 2, 5, 6, 8, 13, 16

Reference (see Section 4) [SAN96] — current

Comments Suite of standards; components developed, withadditional specific device models pending.

• Object Based Equipment Model (OBEM) Standard: This suite of standards defines conceptsbehavior and message services to realize equipment control systems. The OBEM standarddefines the operation of the equipment control systems, including utilization of SANcompliant device level systems and visibility to higher level control systems. Specifically atthe equipment control level requirements addressed by the OBEM standard (either directly orthrough reference) include: integration of control algorithms at equipment control levels,real-time in situ control capabilities, synchronization of data, object-based solutions,visibility of equipment objects to higher level systems (i.e., data accessibility), aspects ofvolume data management, integration of device control algorithms, and remote monitoring.The OBEM achieves specification for these requirements by providing an aggregatedescription of an equipment class and identifying structure and behavior that provides links toother detailed specifications (such as ARAMS).

#2 Specification Object Based Equipment Model Standard

Requirements addressed (from Table 1) 1, 2, 3, 5, 6, 8, 9, 12, 13, 14, 15, 17

Reference (see Section 4) [OBEM97] — pending

Comments Suite of standards; will point to other standardspecifications; should cover all equipment control issues(in much the same way as the CIM Framework coversthe factory control level); will cover cluster tools as wellas single-process tools.


20

• GEM Standard: The GEM standard and emerging Specific Equipment Model (SEM)standards define the generic and equipment type specific behavior of semiconductorequipment as viewed through a communications link in terms of SECS-II messagescommunicated over that link. The links themselves should conform to either the SECS-Ilower speed (RS-232) specification, or the High-Speed SECS Message Services (HSMS)high-speed (Transmission Control Protocol/Internet Protocol (TCP/IP)) specification[SECS97, HSMS97]. The GEM standard is widely used in the semiconductor manufacturingarena. GEM is specified only so that a migration to OBEM from GEM is supported. RelatedSEMs will be incorporated (through reference) in future versions of this document asnecessitated by widespread use, or by incorporation or reference in OBEM documentation.

#3 Specification Generic Equipment Model Standard

Requirements addressed (from Table 1) Not applicable (to be replace by OBEM)

Reference (see Section 4) [GEM96] — existing

Comments Supported so that a migration path to OBEM issupported [OBEM97addendum].

• CIM Application Framework: This specification creates a common environment forintegrating applications and sharing information in a CIM factory domain. The CIM standarddefines the operation of the factory CIM system, including linkage to OBEM-compliantsystems. Specifically at the factory control level requirements addressed by the OBEMstandard (either directly or through reference) include: integration of applications, integrationof equipment into a factory system,, factory level control capabilities, synchronization ofdata, object based solutions, and aspects of volume data management.

Additionally the CIM Framework contains the APC Framework specification; this specificationcovers the integration of run-to-run data collection and control elements (including third-partyapplications) into the equipment control and the factory systems.

#4 Specification CIM Application Framework, including APCFramework

Requirements addressed (from Table 1) 1, 2, 4, 5, 7, 12, 13, 17

Reference (see Section 4) [CIM97] — existing/pending

Comments Modularized standard; can support addition ofapplication (plug-in) standards as they becomeavailable; APC Framework portion is new in 1997.Work has begun on converting portions of theFramework to a SEMI standard.


21

• Wafer Traceability Standard: This standard addresses the traceability of materials (e.g., wafermarking) and other factory resources in the facility.

#5 Specification Wafer Traceability Standard

Requirements addressed (from Table 1) 10, 11

Reference (see Section 4) [WTS97] — pending

Comments Output of Wafer Traceability Committee of SEMI.

5.4 Reliability Domain

The basic specifications in the reliability domain specify equipment structure, operation, controland visibility with respect to specifying, observing and controlling reliability. As such, thesespecifications cover specifying and transitioning between uptime and downtime, equipmentmaintenance procedures, and control system reliability issues. Following are components of thereliability domain specification.

• Automated Reliability, Availability and Maintainability Standard: This standard definesconcepts, behavior and message services to facilitate equipment level capture andcommunication of equipment reliability, availability and maintainability information asspecified in SEMI E-10: Guideline for Definition and Measurement of Equipment Reliability,Availability, and Maintainability (RAM). Requirements addressed by the ARAMS standardinclude specifications for equipment transition between online, offline, scheduledmaintenance, unscheduled maintenance, and other states.

#6 Specification ARAMS Standard

Requirements addressed (from Table 1) 18, 19, 20

Reference (see Section 4) [ARAMS97] — standard

Comments ARAMS standard new in 1997.

• Equipment Maintenance Standard: This standard defines metrics and generic procedures forequipment maintenance that include both scheduled and unscheduled maintenance. It isdifferentiated from ARAMS in that it doesn’t focus on equipment behavior, but rather onprocedures for factory and equipment operation with respect to maintenance. It impactsdocumentation procedures and includes manufacturing execution system (MES) level issues;thus it may include links to online documentation specifications and MES-levelspecifications such as the CIM Framework (see specification #4) and electronicdocumentation standards (see specification #12).

#7 Specification EMS

Requirements addressed (from Table 1) 19

Reference (see Section 4) [EMS99] — envisioned

Comments Could be closely linked to, if not part of ARAMSor RAMS.


22

• Control System Performance Specification Standard: This standard defines metrics andmethods for parameterizing/characterizing the performance of control systems in terms ofresponse time, determinism, bandwidth, etc.

#8 Specification CSPS Standard

Requirements addressed (from Table 1) 2, 16

Reference (see Section 4) [CSPS99] — envisioned

Comments The development of this specification must followthe development of control systems modelingstandards.

• Testability Requirements Specification: This standard defines parameters that describe andfacilitate the testability of control systems with respect to conformance to other requirementsspecifications. Thus, for example it could identify metrics that relate the effectiveness,stability, robustness, etc. of a control solution, and potentially describe methodologies todetermine the values of those metrics.

#9 Specification TRS Standard

Requirements addressed (from Table 1) 20

Reference (see Section 4) [TRS99] — envisioned

Comments The scope of this effort must be further defined.

5.5 Support Standards

A number of standards specify the method of documentation and revision of SEMI standards, orspecify other capabilities in support of control standard compliant implementations. Thefollowing standards are relevant to these support roles.

• Object Services Standard: This standard provides general terminology, conventions, andnotation for describing behavior and data in terms of objects and object attributes. It defines aRumbaugh object-oriented (OO) notation for use in SEMI standard specifications.

#10 Specification Object Services Standard

Requirements addressed (from Table 1) 1–15, 17–23

Reference (see Section 4) [OSS96] — existing

Comments An important tool for developing and understandingall SEMI model-based standards.


23

• Object Library Specification: This standard is a glossary of objects existing in SEMIEquipment Automation/Software standards [1]. Its primary purpose it to promote re-use ofobjects thereby increasing interoperability of systems.

#11 Specification Object Library Specification

Requirements addressed (from Table 1) 1 - 15, 17 - 21, 23

Reference (see Section 4) [OLS98] - envisioned

Comments An important interoperability standard.

• Specification for Electronic Document Interchange (SEED): This standard establishes howdocuments shall be exchanged electronically between two or more entities.

#12 Specification SEED

Requirements addressed (from Table 1) 18–20, 23

Reference (see Section 4) [SEED96] — existing

Comments Specifies, for example hyptertext markup language(HTML) (Worldwide Web [WWW]) for documentinterchange.

6 A CSRS FOR CURRENT AND NEAR-TERM NEXT-GENERATION SYSTEMS

This section provides a CSRS for current and near-term, next-generation systems. Systems towhich this CSRS applies include existing systems (to which the CSRS could be applied to theretrofitting of APC (see Appendix F), and systems to be purchased in 1998, including I300Icompliant systems (see Appendix D). In the following subsections, the need for this CSRS isidentified, issues related to its formulation are given, and the CSRS is presented with a migrationpath to the long-term CSRS vision.

6.1 Introduction and Motivation

The detailed CSRS this section shows that there are many standards and specifications that mustbe developed before a complete CSRS is available. Further, there are some standards that arewidely implemented in today’s systems that are not part of the final CSRS. The long-term visionof the CSRS therefore is not fully compatible with today’s systems. A need is thus identified fora CSRS for current and near-term, next-generation systems. This CSRS should specify existingstandards and specifications and should provide a migration path to the envisioned final CSRS.Further, it should apply not only to specifying new systems, but also to the retrofitting ofenhanced control to existing systems.


24

6.2 Issues

Two major issues must be resolved before a CSRS for current and near-term, next-generationsystems can be realized. The first of these is ensuring that the CSRS represents a realisticassessment of what can be specified on existing systems. A CSRS that cannot be met is uselessas an aid to development of a purchase specification. Table 2 lists the major elements of CSRSpresented in Section 5, and a corresponding analysis of what could be specified for a current ornear-term, next-generation system. Please refer to Section 5 for a more comprehensivedescription of each specification.

Table 2 Analysis of Standards for Current and Near-Term, Next-Generation,CSRS-Compliant Systems

Specification Analysis: Use in Current and Near-Term, Next-Generation Systems

Result: Usablefor Current and

Near-TermCSRS?

SAN Standard SAN standard suite is newly developed and sensor suppliers have begundeveloping products to be SAN standard compliant. SAN standard is thusvery appropriate as a requirement of an incoming system.

YES—for nearterm nxt gen. only

OBEM Standard OBEM is an envisioned standard and thus cannot be part of a CSRS forcurrent or near-term next-generation systems.

NO

GEM/SEM GEM has been provided on most equipment for a number of years. Itshould be a requirement of any incoming system. A number of SEMs haverecently been approved by SEMI and could also be part of a requirement ofan incoming system.

YES—withsupport formigration toOBEM and CIM-FW

CIM and APCFramework

Although the CIM framework has been available for over one year and theAPC framework is complete, a SEMI standard and Framework products arenot yet available. Making Framework compliance a requirement of anincoming system is probably not realistic. However, requiring Frameworkcompatibility of an incoming control system may be achievable. Thisrequirement may be expressed as CORBA compliant, object based solutionwith plug-and-play modular design (e.g., allowing plug-and-play of controlalgorithms, communication drivers, etc.)

NO—but shouldbe supported inmigration path

Wafer TraceabilityStandard

This is not yet a standard, thus it cannot be part of a CSRS for current ornear-term, next-generation systems.

NO

ARAMS Standard ARAMS was accepted earlier in 1997 as a SEMI standard. ARAMS couldbe specified as a requirement of near-term, next-generation systems;however, the requirement may not be met by a number of systems for a fewyears.

YES—dependingon availability

EMS, CSPS and TRS These three specifications are envisioned standard an thus cannot be part ofa CSRS for current or near-term next-generation systems.

NO

OSS This standard specifies the method of documentation of other standardsthus it may not be part of any CSRS. However it could be utilized tospecify requirements for methods of system design documentation.

YES

OLS This standard specifies the method of documentation and re-use amongstandards thus it most likely will not be part of any CSRS.

NO


25

The second issue that must be resolved is ensuring a migration between existing specificationsand the final CSRS. A migration issue is identified wherever a current or near-term,next-generation solution specification is a SEMI standard that is not part of the envisioned finalCSRS. A review of the specifications in Section 5 indicates that a migration issue exists inmoving from current-generation GEM and SEM solutions. Currently, a GEM capability isprovided with most tools. Additionally, SEM capabilities are provided with many tools. In theenvisioned CSRS, GEM and SEM are replaced by OBEM and linked to the APC Framework. Inorder to ensure migration from GEM and SEM compliant solutions to OBEM and Frameworkcompliant solutions, the following additional requirements could be placed on the GEM andSEM solutions:

• The GEM/SEM solution should provide the capability to implement APC (such as run-to-runcontrol) as indicated in the APC Framework specification. Thus, the GEM/SEM solutionmust provide a capability to modify equipment recipe parameters between (and possiblyduring) equipment process runs (see Appendix F).

• The equipment software platform should allow the user to develop a software “shell” thatprovides APC Framework access to the equipment (as opposed to the current GEM/SEMaccess method). This requirement could be expressed to the equipment supplier in terms ofaccessibility to the equipment software programming environment (e.g., via identified“stubs”), and linking capabilities to the equipment control software. In the near term,however, this may not be realistic as OEM equipment controller software is not accessible atthe program level by design. Thus a plausible alternative is a specification to the integrator orcontrol systems supplier in terms of an ability to add a GEM/SEM (SECS) to APCFramework (CORBA) “converter” capability to the system (see Section 6.3 and Figure 3).

• The control systems platform should be capable of utilizing GEM/SEM communications toeffect APC, but should be compatible for easy upgrade to providing the same APC capabilityutilizing Framework methods. This requirement could be expressed as CORBA compliance,modular design, demonstration of rapid plug-and-play capability, and a GEM/SEM interfacemodule that supports a recipe parameter update and end-of-process indication capability thatcould be integrated into a APC Framework interface module.

6.3 A CSRS for Current and Near-Term Next-generation Systems

This specification addresses a number of the control systems requirements listed in Table 1.Because of the lack of a complete suite of CSRS standards, not all requirements can be met withthe existing specification. Further, because some of the standards widely used today will bereplaced in the final CSRS, a migration path must be identified as part of the specification. Asummary of a CSRS for current and near-term, next-generation systems is given in Table 3 andillustrated (control domain only) in Figure 3. It includes a reference to each relevant standard, anidentification of requirements addressed (or partially addressed) by the requirement associatedwith that standard, and comments relating to current implementation of the standard andmigration to a future CSRS compliant solution. Additional information on each standard can befound in Sections 5 and 7.


26

Table 3 A CSRS for Current and Near-Term, Next-Generation Systems

Specification(requirements addressed) Use in Current and Near-Term Next-generation Systems

GEM and SEM Standards

(2, 6, 8, 9, 12, 13, 15, 17,25, 26, 27)

GEM should be a requirement for any current or near-term, next-generationsystem. The communication enabling protocols of SECS-I could be specified,however the higher speed HSMS is preferred as the underlying communicationmedium is better suited to migration to the future CSRS (specifying CORBA-typecommunications over a bus communication system). Additionally, if theappropriate SEM has been accepted as a SEMI standard, it also should bespecified. The GEM specification should include a capability to update recipeparameters between, and possibly during, runs. The preferred update method isthrough modification of equipment constants as detailed in Appendix F.

SAN Standard

(1, 2, 5, 6, 8, 13, 16)

The SAN standard in most cases is not applicable to existing systems, but willbegin to be implemented on near-term, next-generation systems such as 300 mmtools. In most cases, any sensor bus solution on the tool should be required to beSAN standard-compliant, especially if the user anticipates adding sensor capabilityover the bus. Additionally, the tool should provide easy access to the sensor busfor user diagnostics, and should provide a method for integration of a new sensoronto the bus and integration of associated control systems technology into theequipment controller. No standards have yet been developed for these integrationmethodologies.

ARAMS

(18, 19, 20)

ARAMS should be specified for any near-term, next-generation system.Availability should increase significantly over the coming year.

CIM and APC Framework

(2, 3, 4, 5, 7, 8, 14, 25, 26 )

Although these specifications are not standards and implementations are generallynot available, requirements delivered to control systems suppliers and integratorsshould mention Framework compatibility and existence of an upgrade path toFramework compliance. This requirement can be delineated as object orienteddesign, CORBA compliance, and modular plug-and-play design consistent withthe APC Framework.

OSS

(5, 7, 8, 25, 26)

To the extent that any description of internal equipment control software isrequired, a requirement of OSS compliance should be placed on this description.In addition to enforcing consistency in documentation, this requirement also willmotivate object oriented modular software development which is more conduciveto APC and is more aligned with the long-term CSRS vision.


27

Process Flow Management

Standardized High LevelProcess Flow Language

Object-BasedCommunications



• Run-to-Run Process and Equip. Control • • Object Models •

• In-Situ Control Framework • • Object-Based Equipment Models •

• MESC (Cluster Tools) •• Device System Control •

Equipment

Sensor / Actuator Network

Sensor / Actuator Devices• Object-Based Device Models •

Factory Controller

Inter-Process Control(feed-forward and feedback)

Scheduling

GEM,Use of GEM for APC Piggy-BackMigration to OBEM ==> O-O Design

SAN (Sensor Bus Std.)and Point-to-Point

Object-Based Comm.

Product Flow

Not Specified

APC-FI Compatible (not compliant)Migration Path to APC-FI Compliance

Not Specified

Control SystemsSpecification

Figure 3 CSRS for Current and Near-Term, Next-Generation Systems

7 CONCLUSIONS

Section 5 contains a CSRS that references several SEMI standards and SEMATECHspecifications. Section 6 contains a CSRS that is usable to specify current and next-generationsystems today. In both cases, the CSRS is not complete as many of the requirements listed inTable 1 are not fully addressed. This is due to the lack of maturity of control systemsspecification and standardization in the industry. For example, many Section 5 references havenot yet been developed. In this section, the status and potential future direction of control systemsspecifications and this CSRS document are presented. Specifically, Section 7.1 identifies statusand potential direction of incomplete SEMI standard specifications. The ECS-TF and the transferof the CSRS to the task force is discussed in Section 7.2, while Section 7.3 attempts to furtheridentify and rank remaining efforts (that could be undertaken by the ECS-TF) necessary tocomplete the CSRS.

Note that the incompleteness of portions of the specification does not preclude the use ofcomplete portions in specification of elements of a control system. Indeed, Section 6 usesexisting SEMI standards to define a partial CSRS for use with today’s systems. Further, manyincomplete portions still may be used to provide guidelines for requirements specifications.


28

7.1 Control Systems Requirements Specification References and Status

[SAN97] Sensor/Actuator Network Standard Suite, SEMI E-54 [3]. Status—current/pending:The framework for this entire suite of standards has been passed by SEMI.Specifically, the suite overview specification (defining the structure of andinteraction of the standard suite components), standard templates for NetworkCommunication Standard component and Specific Device Model componentconstruction, and the Common Device Model are all SEMI standards [3].Additionally three Network Communication Standards (DeviceNet, LonWorks andSmart Distributed Systems), and one Specific Device Model (mass flow devices)also have been accepted as standards. Other Specific Device Model components arein various stages of development and/or balloting. The future of this standard suiteis directed towards defining additional specific device models, and sensor busnetwork communication mechanisms. There is no known effort to enhance thisstandard to define the device system controller.

[OBEM97] Object Based Equipment Model Standard. Status—envisioned: An OBEM taskforce has been chartered within SEMI and the task force has a working documentthat should be balloted in 1998. The OBEM task force is dedicated to thedevelopment of a next-generation equipment model standard that contains top-down(object aggregation) design components in addition to the traditional grassroots,bottom-up specifications. What this means is that OBEM is expected to specify 1)linkage of equipment controllers to lower level control system components, such asdevice systems and 2), visibility and accessibility to higher level control systemscomponents, such as CIM (equipment integration and APC Framework) systems.Further, the OBEM document is expected to reference other SEMI standards (e.g.,RMS, EM, PM, etc.—see Appendix A) as necessary to provide a completeequipment model standard. Also, note that the OBEM task force is pursuing thereuse and migration of the GEM and SEM models to the OBEM specification.

[GEM97] Generic Equipment Model, SEMI E-30 [3]. Status—existing: GEM is an existingSEMI standard. Although follow-on ballots may modify aspects of the standard, itsoverall structure, approach, and scope is expected to remain constant.

[CIM97] SEMATECH CIM Framework V2.0 [11]. Status—pending: The CIM Framework isan existing specification but not a SEMI standard. Recent enhancements have beenfocused in the area of defining an APC Framework. The overall structure andapproach of the document is expected to remain constant. A task force has beencharted within SEMI to evaluate and possibly pursue the conversion of all or part ofthe CIM Framework to a SEMI standard. Currently, no ballots have been submittedby this task force.

[SECS97] SEMI Equipment Communication Standard, SEMI E-14 and E-5 [3]. Status—current: This standard contains two components. SECS-I is an enablingcommunication protocol describing the communication of SECS-II messages overan RS-232 link between the equipment and a host. SECS-II is a description of themessages that should be communicated over that link to achieve desiredfunctionality. SECS-I and SECS-II together comprise an enabling protocol for GEMand SEM.


29

[HSMS97] High-Speed SECS Message Service, SEMI E37 [3]. Status—current: HSMS is ahigh speed alternative to SECS-I (see [SECS97] reference) that specifies aprotocol for the communication of SECS-II messages over a TCP/IP-compatiblelink. HSMS along with SECS-II is a communication enabling protocol for GEMand SEM.

[WTS97] Wafer Traceability Standard. Status—envisioned: This standard is envisioned asan output of the Wafer Traceability Committee of SEMI. The development andscope of this standard is unclear; however, it is hoped that such a standard wouldaddress the control systems requirements of wafer state information and waferdriven processing specification.

[ARAMS97] Automated Reliability and Maintainability Standard, SEMI E-58 [3]: Status—current: ARAMS became a SEMI standard in 1997. The future direction of thestandard is not known. However, if interest exists, severalreliability/maintainability issues not addressed by ARAMS could be the subject ofARAMS enhancements or other reliability standards.

[EMS99] Equipment Maintenance Standard (EMS): Status—envisioned. This standard isenvisioned as providing structure and commonality to equipment maintenancespecifications and procedures. It should link to ARAMS. It is differentiated fromARAMS in that it does not focus on equipment behavior, but rather on proceduresfor factory and equipment operation with respect to maintenance. It impactsdocumentation procedures and includes MES-level issues; thus, it may includelinks to online documentation specifications and MES level specifications such asthe CIM Framework and SEED [CIM97, SEED96]

[CSPS99] Control System Performance Specification Standard (CSPS): Status—envisioned.This standard is envisioned as providing metrics and methods for parameterizingthe performance of control systems. For example it could be used to specify thedeterminism of a “real time” control system.

[TRS99] Testability Requirements Specification (TRS): Status—envisioned. This standardis envisioned as a result of a SEMATECH (and later) SEMI effort to designmethods and parameters for testing control systems for compliance to standards,and to evaluate correctness, performance, reliability, etc.

[OSS97] Object Services Standard, SEMI E-39 [3]. Status—existing: OSS is an existingSEMI standard. It is being widely utilized in the development of new SEMIEquipment/Automation standards. Document modifications in the form ofenhancements/additions may occur. However, the overall structure and approachis expected to remain constant.

[OLS98] Object Library Specification: Status—envisioned: A SEMI task force was formed(SEMICON/West 1996) that has been addressing the development and promotionof such a specification. However, this task force was sunsetted in 1997 due mainlyto lack of participation. It is hoped that the specification eventually will bedeveloped to promote reuse of object descriptions between standards, thusincreasing the level of interoperability between compliant systems.


30

[SEED96] Specification for Electronic Document Interchange, SEMI E-36 [3]. Status—existing: SEED is an existing SEMI standard. Efforts are currently focusing onfurthering the HTML (WWW) specification component of SEED.

7.2 The Equipment Control Systems Task Force and CSRS Support

ECS-TF was established in July 1997 under the SEMI Information and Control Committee. Theelements of the ECS-TF charter are as follows:

• Utilize CSRS requirements to identify ECS functionality needs

• Map needs to existing and pending SEMI standards

• Identify “holes,” i.e., areas where SEMI standards are needed

• Develop or guide appropriate standards, methods, and/or guidelines

This charter is clearly in line with SEMATECH CSSWG directives. Indeed, the direction of thetask force as indicated in the October 1997 task force kickoff meeting is to use this document asa major resource to address its charter. Further, the task force has indicated a desire to assumeownership and support of this document beginning in 1998.

It is anticipated then that this CSRS specification will be maintained, beginning in 1998, by theECS-TF. Issues that may be addressed by the task force in updating the document are identifiedin Section 7.3. Parties interested in the CSRS and its future migration should contact one of theECS-TF cochairs listed in Table 4.

Table 4 ECS-TF Cochairs

James MoyneMiTeX Solutions, Inc.

[email protected]

John PaceI.B.M.

[email protected]

Steve SpainSpain, Incorporated

[email protected]

7.3 Towards a Complete CSRS: Contributions of the ECS-TF

A review of the control systems requirements (Table 1) reveals that the list is incomplete andshould be prioritized. Further a review of the control systems requirements referenced standards(in Section 6.1) indicates that most of these standards do not yet exist; however, efforts havebegun to develop them. To address these deficiencies and arrive at a more complete CSRS, theECS-TF could undertake the following prioritized list of activities.

7.3.1 Very High Priority Activities1. A cornerstone of the CSRS is the envisioned OBEM standard. The ECS-TF should seek to

work with the OBEM task force to keep abreast of the task force direction, influence thatdirection as necessary, and modify the CSRS as necessary. The ECS-TF should look to theOBEM standard as a new direction in SEMI standards that not only addresses a traditionalgrassroots need for a standard, but also addresses issues of top-down connectivity to otherstandards.

2. The recently mature APC Framework specification should play an important role in theCSRS. Maintaining alignment with this specification is critical and should be activelypursued in 1998.


31

3. A large part of the target audience of the CSRS is the next-generation 300 mm control systemdevelopment community. Thus, maintaining alignment with the I300I effort is critical andshould continue to be actively pursued in 1998. Specifically, as the I300I effort is focused onnear term solutions, Section 6 should be scrutinized to maintain alignment with the I300Ieffort, and additionally to provide a migration path to a complete CSRS.

4. An analysis of the CSRS indicates that a large number of SEMI efforts must be initiated toaddress the development of a complete CSRS. Using the CSRS as a guide, the ECS-TFshould attempt to scope these potential standardization efforts by drafting the appropriateSEMI New Activity Request Forms (SNARFs), and proactively recruiting the associated taskforce members and leaders.

5. An immediate CSRS contribution that should be developed and pursued through SEMI is aGEM enhancement ballot to specify a generic run-to-run capability. Section 6 and AppendixF identify capabilities that should be provided by this ballot proposal.

7.3.2 High Priority Activities6. The ECS-TF should pursue the development of volume data management specifications for

eventual standardization. A volume data management standard (envisioned) is not explicitlyreferenced in the current version of the CSRS, because is anticipated that the standard will bereferenced by the control domain standards such as OBEM and CIM Framework.

7. Methods and metrics for determining and specifying performance of control systems shouldbe investigated by the ECS-TF, and the feasibility of developing a specification in this areashould be investigated.

7.3.3 Medium Priority Activities8. The ECS-TF should assess the need to expand ARAMS to address additional reliability

issues. Reliability domain issues identified as requirements (such as equipment maintenanceprocedures) are not addressed by ARAMS.

8 SUMMARY

This document is a CSRS for semiconductor manufacturing control systems that should be usedto formulate any tool, metrology system, or control system purchase specification. It includes along-term CSRS vision and a practical CSRS applicable to current and near-term,next-generation solutions. The document is not a complete specification, but an umbrella thatprovides a basis for referencing standards that furnish specific details and requirements. Thesereferenced standards are existing, pending, or envisioned. This document is intended a guide formanufacturers to use when compiling purchase specifications that will address a set of controlsystems requirements. The document is also intended as a guide for the development of pendingstandards and motivation for future standards.

The CSSWG (and now ECS-TF) efforts can be considered a success if a version of this umbrelladocument is used as a source reference for development of purchase specifications and as acommunication mechanism between users, OEMs and control systems suppliers.


32

9 REFERENCES

[1] SEMATECH Control Systems Requirements Specification V 1.0, Technology Transfer#96123222A–ENG (December 1996).

[2] 1997 Control Systems Requirements Specification Roadmap, SEMATECH internaldocument and presentation at SEMATECH Project Technical Advisory Board Meeting,(July 1997).

[3] SEMI International Standards 1996: Equipment Automation/Software 1 and 2,Semiconductor Equipment and Materials International, 1996.

[4] J. Moyne, “Towards a Control System Requirements Specification for SemiconductorProcessing Equipment Applications,” presentation to SEMATECH Control StandardsWorking Group, Austin, TX, (July 1996).

[5] J. Moyne and J. White, Report #1: Glossary of Documents Related to Development of aControl System Requirements Specification, internal report, SEMATECH ControlStandards Working Group, Austin, TX, (June 1996).

[6] J. Moyne and J. White, Report #2: Control Standards Roadmap for SemiconductorManufacturing: A White Paper, internal report, SEMATECH Control Standards WorkingGroup, Austin, TX, (June 1996).

[7] PTAB Meeting Minutes: March 5, 1996 Working Group Meeting, internal report,SEMATECH Control Standards Working Group, Austin, TX, (March 1996).

[8] J. White, “Project Objectives: Control System Standardization,” presentation toSEMATECH Control Standards Working Group, Sunnyvale, CA, (February 1996).

[9] J. Moyne, “Future Directions in SEMI Standardization,” presentation to SEMATECHControl Standards Working Group, Austin, TX, (January 1996).

[10] AEC Preliminary Requirements and Functional Capabilities, Version 1.0, TechnologyTransfer #95123035A–TR (January 1996).

[11] Computer Integrated (CIM) Framework Specification Version 2.0, Technology Transfer#93061697J-ENG (anticipated publication in 1Q98); and Advanced Process ControlFramework Initiative, V1.0, Technology Transfer #97063300A–ENG (1997).

[12] J. Moyne, H. Etemad, and M. Elta, “Run-to-run Control Framework for VLSIManufacturing,” Microelectronic Processing ‘93 Conference Proceedings, (September1993).

[13] National Technology Roadmap for Semiconductors, Semiconductor Industry Association,1997.

[14] CIM Global Joint Guidance for 300 mm Semiconductor Factories, Release One,International 300 mm Initiative (I300I) and Japan 300 mm Semiconductor TechnologyConference (J300), (December 1997).

[15] Control Systems Requirements Specification for SCADA Systems, SEMATECH internaldocument (to become ECS-TF working document), SEMATECH, (December 1997).


33

APPENDIX A

Control Systems Requirements Specification

Glossary of Documents

The following is a glossary of SEMI Standards, pending SEMI Standards, SEMI activities, andSEMATECH specifications that relate to a control systems requirements specification [5]. Theglossary is divided into three categories: SEMI Standards, Pending SEMI Standards (whichinclude SEMI activities), and SEMATECH Documents. Within each category entries are arrangedin alphabetical order.

SEMI Standards:

STANDARD DESCRIPTION

Cluster Tool Module Communications(CTMC) Standard

This standard addresses communications with and among moduleswithin a cluster tool. This is a component of a suite of standards forcluster tools being developed by the Modular equipmentSubcommittee for Communications (MESC). For this reason ,thestandard suite is sometimes referred to as the MESC standards.Because a cluster tool is considered a tool in the context of acontrol systems requirement document, the CTMC standardimpacts the CSRS in the areas of internal cluster tool equipmentcommunication and control.

Exception Management (EM) Standard This standards addresses exception management with and amongmodules within a cluster tool. This is another MESC standard.Because a cluster tool is considered a tool in the context of acontrol systems requirement document, the EM standard impactsthe CSRS in the areas of internal cluster tool equipmentcommunication and control.

Generic Model for Communications andControl of SEMI Equipment (GEM)

The GEM standard defines the generic behavior of semiconductorequipment as viewed through a communications link in terms ofSECS-II messages communicated over that link. The GEMstandard impacts equipment control and equipment to “host”communications in the context of the CSRS. Note that GEM doesnot comply with the distributed object-based control descriptionparadigm; the OBEM output may be a more suitable replacementfor GEM in a CSRS.

High-Speed SECS Message Services(HSMS) Standard

HSMS is intended as an alternative to SECS-I for applicationswhere higher speed communication is needed or where simplepoint-to-point technology is insufficient; HSMS defines acommunication interface suitable for the exchange of (SECS-II)messages between computers in a semiconductor factory. AlthoughHSMS (TCP/IP) is definitely preferable to SECS-I (RS-232) in thecontext of a CSRS, HSMS defines a communication environmentthat is not conducive to distributed object-based communications(e.g., CORBA). CIM Framework and OBEM communicationmethodologies may be a more suitable replacement for HSMS.


34


Material Movement Management Standard(MMM)

This standard addresses the communication needs of thesemiconductor manufacturing facility with respect to materialmovement. In the context of the CSRS it could define thecommunication structure and behavioral model for materialmovement.

Object Services Standard (OSS) The purpose of the OSS is to provide general terminology,conventions, and notation for describing behavior and data in termsof objects and object attributes. It defines a Rumbaugh

object OO

oriented (O-O)notation for use in SEMI standard specifications. A

LLll model standards in the CSRS from the equipment controllevel up through the factory control level should be OSS

-compliant.

Recipe Management Standard (RMS) This standard defines the concepts, behavior, and services tosupport the integration of automated recipe management within asemiconductor factory. In the context of the CSRS it could definethe recipe management between the equipment control andrun-to-run host control levels. Portions of the RMS specificationmay have to be modified so that the specification is more in line.

SEMI Equipment CommunicationsStandard (SECS)

SECS is a standard for communications between intelligentequipment and a host. The standard defines the communicationprotocol interface (SECS-I) and the messages exchanged(SECS-II). SECS-I, which specifies point-to-point communicationsover a (slow) R2-232 interface is obsolete; HSMS is a high-speedreplacement, but retains many of the deficiencies of SECS-I (e.g.,point-to-point, host-equipment—master/slave, etc.). The entireSECS paradigm is inconsistent with the object-basedcommunication mechanisms that should be part of a CSRS. Effortsin the CIM Framework Specification and OBEM could generatesuitable replacements for SECS.

Specification for Electronic DocumentInterchange (SEED)

The purpose of this standard is to establish how documents shouldbe exchanged electronically between two or more entities.Specifications of this type are needed at all control levels in aCSRS.

Standard for Process Management (PM) This standard addresses the communications within thesemiconductor manufacturing environment with respect to theprocessing of material in a tool. In the context of a CSRS it couldserve as a departure point for describing control standards thataddress parameterization of control, integration of third partysoftware (algorithms), combining run-to-run and in situ control,etc.


35

Pending SEMI Standards:


Automated Reliability, Availability andMaintainability Standard (ARAMS)

This standard defines concepts, behavior and message services tofacilitate equipment level capture and communication of equipmentreliability, availability and maintainability information as specifiedin SEMI E-10: Guideline for Definition and Measurement ofEquipment Reliability, Availability, and Maintainability. Thisstandard is part of the 1997 Book of SEMI Standards. ARAMSshould be expanded in the context of the CSRS as the addition ofstandards for control raise numerous reliability and maintainabilityissues.

Sensor/Actuator Network (SAN)Standards

This suite of standards defines concepts, behavior and messageservices to facilitate device level communication over aSensor/Actuator Bus, thereby integrating sensors and actuators intothe equipment control system. Examples of devices include massflow device, particle counter, capacitance manometer, etc.Components of the standard include sensor/actuator network (i.e.,sensor bus) communication standards (NCSs), a common devicemodel (CDM), and specific device models (SDMs). The SAN suiteis part of the 1997 Book of SEMI Standards . Three NCSs and oneSDM (mass flow device) are part of this suite. Additional SDMsand possible two NCSs will be added to the suite in 1998. The SANstandards should be a critical component of the CSRS as theyaddress (in an object based, OSS-compliant, manner) many issuesinvolved with integration of a sensor/actuator into a control system.What is not addressed by this suite of standards is the integration ofassociated control software at the equipment/process controller.

Object Based Equipment Models (OBEM) The goal of the relatively new OBEM effort within SEMI is todevelop a replacement to GEM that is protocol-independent and thatis based on the OSS object model paradigm. It will allow a hostsystem to reference components of equipment, including currentstatus (attributes), and elicit and observe behavior in the equipmentthrough service calls. Interfaces to the host system and low-levelsensor bus systems are defined; however, interaction with the APCFramework specification is not clear. This effort has matured to thepoint that an OBEM ballot is expected to be submitted in 1998.


36

SEMATECH Specifications:


User Interface (UI)/Style Guide The SEMATECH Strategic Cell Controller (SCC) User InterfaceStyle Guide (Technology Transfer #92061179A–ENG) is aspecification of guidelines for user interfaces (also referred to asMan-Machine Interfaces or MMIs). The specification identifiesguidelines and conventions for developing user interfaces that arecharacterized by a “common look and feel.” In the context of aCSRS, the Style Guide represents a first step in defining a commonuser interface (UI). Standardization in the area of UI and MMI isconsidered outside the scope of the CSRS.

SEMATECH CIM ApplicationFramework

The CIM Framework Specification is a specification for a softwareinfrastructure that creates a common environment for integratingapplications and sharing information in a CIM factory domain. Thisaggressive specification makes widespread use of distributed objectbased descriptions to identify factory level applications and theirinteraction in terms of plugable object oriented specifications. Theintent is provide a modular system design so that suppliers maydevelop factory level applications that integrate more easily andquickly with a other compliant applications to form a CIM system.The specification now includes the Advanced Process ControlFramework that defines the implementation of host-level controlcapabilities. In the context of a CSRS, the CIM Framework goes along way to address the majority of factory control issues. Theapproach is very current in that it utilizes object-based OSScompliant modeling specifies CORBA-compliant communicationstrategies.


37

APPENDIX B

Control Standards Roadmap for the Semiconductor Industry:A White Paper

James Moyne and Joe WhiteJune 1996

B.1. Introduction

This appendix derives a control standards roadmap for the semiconductor industry [6].Specifically, this appendix identifies the role of existing and pending SEMI EquipmentAutomation Software standards as well as pertinent SEMATECH specifications insemiconductor manufacturing control systems. The appendix proposes how these specificationsmight “fit together” in a control systems specification. Additionally, this appendix identifieselements of a control systems specification where there are no current or planned SEMIstandards, thereby suggesting potential areas for future SEMI standardization.

This appendix is organized as follows:

• Section B.2 provides background information on the motivation for developing a SEMIstandards roadmap.

• Section B.3 introduces SEMI standards, pending standards and SEMATECH specificationsthat potentially play a role in a control systems specification.

• Section B.4 proposes a roadmap tying these specifications together.

• A conclusion contains an informal discussion of additional areas where SEMI standardizationshould be pursued to complete the standards roadmap.

B.2. Background and Motivation

The development of SEMI standards in equipment automation and control has been growingexponentially since the first of these standards, SECS-I, was first published by SEMI in 1979.Indeed, of the 13 “E” standards contained in the Equipment Automation standards volumes(I and II), eight are less than two years old (see Figure 4). Further, an even larger number ofequipment automation standards are in various stages of development in SEMI committees [1, 2,3, 6].

Due to the process within SEMI by which standards are developed, most of today’s standardsarose from grassroots efforts to address specific needs in the industry. While this approach serveswell to solve immediate problems in the industry, it does little to identify an overall standardsroadmap [3, 6, 13].

The CSSWG realizes that existing SEMI standards and those under development in this areamust play an important role in the development of a CSRS. Unfortunately, as noted above, thereis no explicit framework for SEMI standards in equipment automation and control. Clearly, aroadmap that provides an understanding of the collective role of SEMI standards in the area(existing and upcoming), is a critical initial step in realizing a control systems requirements


38

specification for the industry. Such a roadmap would provide many benefits including thefollowing:

1. Informing CSSWG members of the various SEMI standards that may impact the controlframework and providing brief to-the-point descriptions of these standards

2. Illustrating how the various standards might be utilized collectively in a control solution, thusproviding impetus for the development of standard control requirements

3. Identifying the “holes” in the framework, i.e., areas where specifications are needed, but nocorresponding SEMI standardization effort has yet been undertaken

4. Aiding in the identification and scoping of future efforts that would be necessary to completea CSSWG control requirements specification “umbrella document” and associated userrequirements purchase specification

SMIF

1980 1985 1990 1995

SECS-I SECS-II SMS GEM MMM

EDI

HSMS

CMTC

OSS

PM

EM

RMS

Figure 4 The SEMI Equipment Automation and Control Standards Timeline

B.3. Components of the Roadmap

The first step in constructing a control standards roadmap is identifying the components of thatroadmap, i.e., the specific SEMI standards that are expected to play a role in a CSRS. A reviewof existing SEMI standards reveals that, although there are a variety of communicationsstandards (a necessary component of a CSRS), there are still large gaps in the definition of thecontrol systems themselves [6]. However, various task forces within SEMI are addressing aspectsof control system standardization, and SEMATECH has produced various specifications on thetopic. Although the results of these efforts are not (yet) standards and indeed may not be fullydefined, they should nevertheless be considered (as concisely as possible) as components of theroadmap as they do generally represent the consensus or direction of the industry.

B.4. A SEMI Standards Control Systems Roadmap

The Control System

Although the components of a control systems roadmap have been identified in Section 2, theroadmap cannot be constructed until the general form of the control system for the industry isdefined. As might be expected, factory control system designs and implementations in theindustry vary widely. In order to define a control systems roadmap, and indeed an effectivecontrol systems requirements specification, a general form of a control system must be identifiedthat encompasses all of these designs. Luckily, due to factors such as SEMI standards, de factostandards, accepted software solutions, and common functionality requirements, threads ofcommonality can be identified in control solutions throughout the industry.

A logical view of the semiconductor factory control system is illustrated in Figure 5 [12]. In thisfigure, a hierarchical approach to control is indicated with three basic control levels identified:in-situ, run-to-run, and factory-level. At the in situ control level, basic continuous equipment


39

control is achieved, along with potentially, in situ (and possibly real time) process control. At therun-to-run control level, ex situ process quality information is utilized to affect a recipeimprovement for the next run. Also at this run-to-run control level, new recipes are downloadedor selected as necessary to achieve a (new) product specification. At the factory control level,functionality such as factory-wide process flow management, equipment scheduling, factorydesign, and potentially interprocess (feed forward and feedback) control are achieved.

It is important to note that the control system depiction of Figure 5 is a logical view. A physicalimplementation may combine elements of layer functionality so that the resulting system hasonly two physical levels. Also, note that the breakdown of the control system into three layersdoes not prevent an implementation from supporting additional layers. As an example, therequirement of factory control could be subdivided into a number of layers so as to group“banks” of similar equipment, provide area control, etc.

GEM / SECSHSMS



• Run-to-Run Process and Equip. Control •

• In-Situ Control Framework • • GEM •

• MESC (Cluster Tools) •

Equipment

Standardized Sensor Bus

Smart Sensors

Factory Controller

Inter-Cell Control

Factory Design SEMATECHCIM Framework

OBEM??

SAN (Sensor Bus Std.)

FUTURE ??

Figure 5 Logical View of the Semiconductor Factory Control System


40

The Roadmap

The mapping of SEMI standards, pending standards and SEMATECH specifications into thecontrol system of Figure 5, is described in the following paragraphs. The issues that could beaddressed by a control systems requirements specification at the various levels of control areindicated in Table 1 (Section 3).

The description of the mapping is presented by defining, at each level, as well as at the interfacesbetween adjacent levels, the relevant standards components and their potential interaction.

In-Situ (Equipment) Control Level

At the equipment control level, functionality includes continuous equipment control, andpotentially in situ process feedback control that may include real-time control elements. Table 3contains a summary of the potential roadmap elements (listed in Table 1) and their potentialparticipation in a control systems specification at the equipment control level. Table 4 containsthe same summary, but focuses on the interface between the equipment control and run-to-runcontrol levels.

Table 5 Roadmap: Equipment Control Level

Equipment (In-Situ) Control Level

Element Impact Comments

SECS(I and II)

Low • Does not address internal equipment communication and/or control

• SECS-I (RS-232) is obsolete. Should be replaced by HSMS for transfer of SECS-IIinformation.

• In the (very) long term, SECS-II may be replaced by a more object orientedapproach (e.g., CIM Framework at the Tool interface level)

GEM Medium • Addresses equipment visibility as seen from above, which implies equipmentmodels, including control models.

• Does not address non-visible structure and behavior.

• May be obsolete. Not CIM Framework-compliant. May be replaced by OBEM.

MMM Medium • Deals with communications required for transfer between equipment. Only definesexternally visible behavior (to the factory host) necessary for material movement.

SEED High • Electronic document interchange impacts all levels of the control roadmap.

HSMS Low • Addresses low level aspects of interface (from host) to equipment.

CTMC High • A cluster tool is considered a single tool, therefore communications within thecluster tool is necessarily part of equipment control.

OSS High • The future OBEMs will draw heavily on OSS terminology, conventions andnotation. OSS provides a common language for defining object based equipmentmodels (of the future).

PM High • PM focuses on process management within a cluster tool. Otherwise it is applicableto host control of equipment.

• It addresses feedforward and feedback control within a cluster tool to a minorextent.


41

Equipment (In-Situ) Control Level

EM High • It addresses interactive exception within a cluster tool.

RMS High • High applicability in context of a cluster tool

• Lower applicability otherwise (host to equipment behavior)

ARAMS High • Describes equipment behavior for residing in and transitioning between Productive,Standby, Unscheduled Downtime, Engineering, Non-Scheduled Time, andScheduled Downtime states.

• Utilizes the OSS paradigm

SAN(Sensor bus)

High • Describes communication between equipment controller and its sensors andactuators.

• Provides for development of distributed object based description and control

• Through common and specific device models, describes integration of sensor and/orcontroller into equipment control system.

• Does not address integration of control elements (i.e., software into equipmentcontrol system as part of sensor integration).

• Utilizes the OSS paradigm.

OBEM High • Object based replacement to GEM

• Specification in very early stages of development


UI Medium • Addresses general form of equipment UI.

CIM Frame-work

Low • A higher (factory) level specification

• Could link to OBEM models via CORBA.


42

Table 6 Roadmap: Interface Between Equipment and Run-to-Run Control Levels

Interface Between Equipment and Run-to-Run Control Levels(i.e., Equipment to Host—Today)


SECS

(I and II)

High • Addresses communication between these levels.

• SECS-I is obsolete and should be replaced with HSMS.

• SECS-II is becoming obsolete and should be replaced with a CORBA object basedapproach to communications (e.g., as in the CIM Framework)

GEM High • Addresses formalized communications between these levels.

• Possibly becoming obsolete as it is not object based communications, howevermuch of the specification is re-usable in an object based communication scheme;possibly replaced by OBEM in the future.

MMM High • Defines use of the interface for material movement


HSMS High • Replacement for SECS-I

• It may in turn be replaced by an object-based CORBA communication scheme(long- term).

CTMC Low • Deals with communications within a cluster tool. Cluster tools generally employGEM to communicate with a host.

OSS High • Future specifications at all levels should draw heavily on OSS terminology,conventions and notation. OSS provides a common language for defining objectbased equipment models (of the future).

PM High • PM focuses on process management within a cluster tool. Otherwise, it is applicableto host control of equipment.

EM Low • It addresses interactive exception within a cluster tool.

RMS High • High applicability in defining host to equipment behavior

• Low applicability in context of a cluster tool

ARAMS High • Describes equipment behavior; however, this behavior is made externally visiblethrough the interface.


SAN(Sensor bus)

Low • Describes communication between equipment controller and its sensors andactuators. Should not be utilized for Equipment-to-Host interface.

OBEM High • Object-based replacement to GEM

• Should specify external visibility of equipment (structure and behavior) as viewedthrough this interface.

UI Low • Addresses general form of equipment UI.

CIM Frame-work

Medium • Does not come down to this level at this time.

• Could specify linking of OBEM models via CORBA.


43

Run-to-Run (Host) Control Level:

At the run-to-run control level, functionality includes sequential (i.e., non-continuous) run-to-run control., andscheduling. Table 7 contains a summary of the potential roadmap elements (listed in Table 1) and their potentialparticipation in a control systems specification at the run-to-run control level. Table 6 contains the samesummary, but focuses on the interface between the run-to-run control and factory control levels.

Table 7 Roadmap: Run-to-Run Control Level

Run-to-Run (Host) Control Level


SECS

(I and II)

Low • Addresses communications from host to equipment

• In the (very) long term, SECS-II may be replaced by a more object oriented approach(e.g., CIM Framework at the Tool interface level)

GEM low • Addresses equipment visibility as seen from the host.

• The idea of a host specific equipment model has been discussed, but not pursued.This may be pursued under the OBEM task.

MMM low • Deals with transfer between equipment.



• Replacement for SECS-I

CTMC Low • Defines internal cluster tool communications.

OSS High • The future OBEMs and run-to-run controller models should draw heavily on OSSterminology, conventions and notation. OSS provides a common language fordefining object based equipment models (of the future).

PM Medium • PM focuses on process management within a cluster tool. Otherwise it is applicableto the interface for host control of equipment.

EM Low • It addresses interactive exception within a cluster tool

RMS High • Defines host-to-equipment behavior for recipe management.

• Could be expanded to further define run-to-run (host) recipe management.

ARAMS Low • Describes equipment behavior. Important to run-to-run control level only in that theequipment states are externally visible


SAN(Sensor bus)

Low • Describes communication between equipment controller and its sensors andactuators.

OBEM High • Object based replacement to GEM. Could define the run-to-run controller model.



UI Low • Addresses general form of equipment UI. Could be extended to run-to-run controllerUI.

CIM Frame-work

High • As a higher (factory) level specification, it enforces visibility of run-to-run controllevel structure and behavior.

• Could link to OBEM models via CORBA.


44

Table 8 Roadmap: Interface Between Run-to-Run and Factory Control Levels

Interface Between Run-to-Run and Factory Control Levels(i.e., Host to Factory — Today)


SECS

(I and II)

Low • SECS should not be utilized at this level.

GEM Low • GEM models should not be visible at this level (with the possible exception of anyhost model that is developed).

MMM Low • Does not address material movement at this high level

SEED Medium • Electronic document interchange impacts all levels of the control roadmap, howeverthe standard in its current form is not as applicable at higher levels.

HSMS Low • HSMS should not be utilized at this level.

CTMC Low • Deals with communications within a cluster tool. Cluster tools generally employGEM to communicate with a host.

OSS High • Future specifications at all levels should draw heavily on OSS terminology,conventions and notation. OSS provides a common language for defining objectbased equipment models (of the future).

PM Low • PM focuses on process management within a cluster tool or between host controllerand equipment.


RMS Medium • Does not address recipe management at a high level, however some of the conceptscould be extended.

ARAMS Low • Describes equipment behavior.

SAN(Sensor bus)


OBEM Medium • Should specify external visibility of equipment (structure and behavior) that in somecases may be viewed through this interface.

UI Low • Addresses general form of equipment UI

CIM Frame-work

High • Specifies an object based CORBA Compliant factory CIM system. Elements offunctionality within the factory system (e.g., scheduler, machine/process control, etc.)are defined as plugable applications with information models, structure, behavior,and external visibility defined. The portion of this specification that directlyaddresses the run-to-run to factory control levels interface is the CORBA-compliantobject brokerage scheme defined.


45

Factory Level Control Level:

At the factory level control level, functionality includes factory wide issues such as process flowcontrol, and scheduling. Table 7 contains a summary of the potential roadmap elements (listed inTable 1) and their potential participation in a control systems specification at the run-to-runcontrol level.

Table 9 Roadmap: Factory Control Level

Factory Control Level


SECS

(I and II)

Low • Addresses communications from host to equipment

GEM low • Addresses equipment visibility as seen from the host.

MMM low • Deals with transfer between equipment.

SEED Medium • Electronic document interchange impacts all levels of the control roadmap; however,the standard in its current form is not as applicable at higher levels.


CTMC Low • Defines internal cluster tool communications.

OSS High • The future OBEMs and factory level application descriptions should draw heavily onOSS terminology, conventions and notation. OSS provides a common language fordefining object based models (of the future).

PM Low • PM focuses on process management within a cluster tool.


RMS Low • Defines host-to-equipment behavior for recipe management.

• Could be expanded to further define higher level recipe management.

ARAMS Low • Describes equipment behavior.

SAN(Sensor bus)


OBEM Medium • Object-based replacement to GEM. Could define the run-to-run controller model andvisibility at the factory control level.



UI Low • Addresses general form of equipment UI. Could be extended to factory-level UIdescription.

CIM Frame-work

High • Attempts to address nearly all generic aspects of factory level control. Specifies anobject based CORBA Compliant factory CIM system. Elements of functionalitywithin the factory system (e.g., scheduler, machine/process control, etc.) are definedas plugable applications with information models, structure, behavior, and externalvisibility defined.


46

Summary

With the information provided in Tables Table 3 through Table 7, conclusions can be drawn withrespect to the level at which current issues identified as important to a control systemsrequirements specification (see Table 2) have been addressed by current and pending SEMIstandards and SEMATECH specifications. These conclusions are listed in Table 8.

Table 10 A Mapping of Control Systems Requirements Issues into Current andPending SEMI Standards and SEMATECH Specifications

Issue

Relevant*Standards

and/or Specs. Comments

Synchronization/timestamping of data

CTMC to asmall extent

• Although capabilities are available within GEM/SECS totime stamp data, the addressing of this issue needsformalization.

Run-to-run controlcapability

PM to a smallextent, possiblyOBEM

• Although not excluded by SEMI standards (GEM, SECS,RMS, etc.), this capability should be addressed moreformally. Integration of third-party software is animportant issue. The OSS paradigm provides a method forsoftware module specification in a run-to-run system. Theplugable application paradigm described in the CIMFramework may be reusable. This task may be undertakenby the OBEM task force.

Sensor integration intothe control system

SAN • The sensor bus standards are working toward definingcommon and specific object based models which willfacilitate modular description of sensor systems and easierintegration of sensors into systems. What is not addressedis the method for integration of control level softwareassociated with the sensor. The approach mentioned abovealso may be applicable here and should link easily into theOSS compliant SAN specifications.

High speed networkcompliance

HSMS, CTMC,GEM, OBEM

• TCP/IP communications and communications standards inthe industry are wide-spread. The CORBA specification ofthe CIM Framework, and probably the OBEMspecifications, will provide a standard structure fornext-generation distributed high-speed communications(which will give applications network transparency).

Defining a successor toSECS-II GEM thatdelivers higherthroughput

OBEM, CIMFramework

• One goal of OBEM is to provide better equipment models.Due to object based descriptions and object based networkcommunications, the resulting system should have a higheroverall throughput.

Defining equipmentcontrol system utilizing astandard object basedparadigm

SAN, OBEM,CIMFramework,MESC

• Most of the recent standards and specifications (1995 andlater) are embracing the object-based paradigm. A move tothis paradigm will make SECS-II and GEM obsolete;OBEM efforts within SEMI should provide object-basedreplacements for these specifications.

Wafer state information None • The traceability committee within SEMI is chartered to“...develop standards to enable full traceability of materialsand other factory resources in semiconductormanufacturing.” A review of the current activities of thiscommittee, however, seems to indicate that this committee


47

Issue

Relevant*Standards


has expanded its efforts to include software capture ofwafer state information for control. This should beinvestigated further to (1) identify what has beenaccomplished by the traceability committee and (2) howthe software control systems requirements developed inthis area should link to traceability specifications.

• Maintenance of wafer state information should be acomponent of OBEM.

Wafer driven processing None • As with the wafer state information issue, this issue willimpact the traceability committee and OBEM.

Volume data management RMS, CIMFramework

• Further investigation is needed into the level at which theCIM Framework address volume data management.Volume data management at the run-to-run and in-situcontrol levels is not addressed in any generic sense.

Defining dataaccessibility

SAN, OBEM,CIMFramework

• The object-based specifications provide a specification fordata accessibility (SAN for accessibility to the equipmentcontrol system, OBEM for accessibility to the run-to-runcontrol and CIM system, and CIM Framework foraccessibility between applications at the factory controllevel). This issue should be addressed by a CSRS thatincludes these mature specifications.

Integration of controlalgorithms at equipmentand run-to-run level(without affecting integrityof control system or tool)

CIMFramework toan extent

• The object-based paradigm provides a methodology fordescribing and implementing systems that allowintegration of third-party control algorithms in thismanner. Specifications at the equipment and run-to-runcontrol level should include these specifications.

User interfacespecifications

Style Guide • User interface specifications are an important part of aCSRS at all control levels. The SEMATECH Style Guideprovides general guidelines for Is. Note that a HumanComputer Interface Task Force was chartered within theInformation and Control Committee of SEMI, but wasdisbanded, partly because of low levels of participation.

Defining a “ControlLanguage” for processengineers to use

None • This issue probably falls outside the scope of plannedSEMI standards activities.

Real-time in-situ controlcapabilities

None • See also 23. Specifications for parameterizing in-situcontrol capabilities have not been developed.

Specifications. forcombining run-to-run andin-situ control

None • Specifications addressing this issue have not beendeveloped, but should result from providing theappropriate of visibility of equipment information throughobject-based specifications (e.g., OBEM), followed bywriting a specification for use at the run-to-run level thatutilizes this visibility to effect run-to-run control.

Equipment maintenance ARAMS • Object-based equipment models are presented in ARAMSdefining equipment behavior in transitioning to and from

3 NOTE TO AUTHOR: What does “2” refer to here?


48

Issue

Relevant*Standards


operating states, including scheduled and unscheduleddowntime. These should integrate with any upcomingspecifications (e.g., OBEM).

Specifications. for remotemonitoring

GEM, OBEM Remote monitoring is specified in GEM and likely will bespecified in OBEM.

* Note that only the standards and specifications listed in Table 1 are considered. There may be other(non-equipment automation software) SEMI standards and/or SEMATECH specifications that address the listedissues. Although the exploration of these additional specifications should be undertaken by the CSSWG, theexploration is beyond the scope of this appendix.

Conclusions

In this appendix, SEMI standards, pending standards, and SEMATECH specifications in the areaof control systems have been defined and evaluated in the context of addressing issues identifiedas pertinent to a control systems requirements specification. The following are importantconclusions drawn from that analysis.

1. SEMI to date has been focusing primarily on aspects of communication between a host andequipment. There are many holes in the standards roadmap in the area of equipment andrun-to-run control specifications.

2. The general trend is towards OSS distributed object-based specifications. All future controlsystem standards should utilize the object based paradigm. SECS, GEM and HSMS, thoughwidely used today, do not fit well in this paradigm. Mature OBEM and SEMATECH CIMFramework results will force SECS, GEM and HSMS into obsolescence.

3. There are a number of SEMI standards that need to be developed at the equipment controllevel. The SAN (sensor bus) standards address the integration of a sensor into the controlsystem. The ARAMS standard addresses reliability. Both are consistent with the object-basedtrend of current control system models. Other standards should address the integration ofcontrol software in the system (e.g., third-party sensor control software) without impactingthe integrity of the system. This standard should take the approach of modeling theequipment control system as generically and as modular as possible utilizing the objectoriented paradigm. It should provide external visibility of critical components of the controlsystem as necessary so that a specification could be developed that addresses combiningequipment (real-time) and run-to-run control. Standards also should be developed so that thecapabilities of real-time, in situ control systems can be formally specified.

4. Similarly at the run-to-run control level a number of SEMI standards are needed. Therun-to-run control model needs to be formalized in as modular a fashion as possible (utilizingobject-based constructs). Specifications should be derived for integration of third-partysoftware corresponding to elements of functionality. Much of the approach utilized in theCIM Framework may be reused here. The position of the run-to-run controller with respect tothe equipment controller and Factory CIM system needs to be better defined.


49

5. The results from the OBEM effort will play a critical role in a control system requirementsspecification. It should define the interaction of the equipment with the run-to-run controlsystem as well as the factory CIM system in terms of object structure and behavior. It shouldprovide a framework that will support standardized in-situ control systems (see point 3above) as well as reliability standards such as ARAMS.

6. The CIM Framework should be extended slightly to provide an interface to run-to-run controland equipment objects. The CIM Framework should be addressed within SEMI.

7. Specifications for synchronization/time stamping of data are needed. These probably shouldbe part of the equipment control, run-to-run control, OBEM and CIM Framework standardsmentioned above.

8. Standards for volume data management are needed. The development of these standardscould be somewhat orthogonal to the development of those identified above.

9. User interface standards at all levels are needed. However, the interest within SEMI in thisarea so far has been low. A SEMATECH specification (e.g., an extension of the style guide)may be appropriate in the interim.

10. A “Control Language” standard is needed. The development of this standard could besomewhat orthogonal to the development of those identified above.

11. Standards that provide for wafer-driven processing should be considered, or more likely,control standards should allow for wafer-driven processing. Additionally, these standardsshould provide for the capture and storage of wafer state information.

In summary it appears that a significant number of efforts must be undertaken before a maturecontrol systems requirements specification can be achieved. However, as basic elements in aCSRS have been defined, and general consistent trends in standardization identified, an umbrelladocument now may be constructed that will focus and coordinate future SEMI efforts in this areaand define a path toward a mature specification.


50

APPENDIX C

Control Systems Requirements Specification

Glossary of Terms

Following is a glossary of terms used in this document. These definitions are derived whereverpossible from relevant literature and discussions with CSSWG members. Note that, becausethese definitions have not yet been reviewed by the community as a whole, and because theyoften represent concepts that are not yet fully developed, the definitions themselves may evolvein later versions of the CSRS. Included with each definition is a brief discussion of the impact ofthe term on the CSRS.

CSRS Terminology:

TERM PROPOSED DEFINITION and IMPACT

Fault Detection andClassification

Usually refers to analysis of equipment and process “fingerprints” or datatraces to detect and classify equipment operation errors and processing faults.The analysis generally occurs at the equipment level, making use of real-timemonitoring data. However, fault detection and classification could take place athigher control levels and make use of higher (discrete) data.

Fault detection and classification is addressed in the CSRS as anequipment-level requirement.

Feed-forward Control Also called downstream control in some applications, is any type of control thatutilizes information to correct for the current product quality by adjusting partof the processing that is to occur later (i.e., downstream) on that product. Forexample, the recipe for a downstream (future) lithography mask step may bemodified to compensate for an etch undercut step in the current mask level.

Feedforward control is a critical requirement in the CSRS in the area ofinterprocess control.

Feedback Control Also called upstream control in some applications, is any type of control thatutilizes information to correct for future (upstream) occurrences of the processevent. For example, during processing, feedback control may try to adjust for alow etch rate by raising the fluorine level for the rest of the etch. At the factorylevel, feedback control may be utilized to adjust the scheduling algorithm forfuture orders in response to a current order that was not produced on time.

Feedback control is a critical requirement in the CSRS, expressed as a need forreal-time, run-to-run and interprocess control.


51

TERM PROPOSED DEFINITION and IMPACT

interprocess Control A form of discrete control where results of a process (usually expressed in highlevel terms such as with process flow language syntax) is utilized to impact theprocess throughout the factory in the form of feedback or feedforward controladvices to other processes in the facility. For example, if the overreach error inan etch step exceeds the target by more than a predetermined amount, theinterprocess controller may perform the following actions.

– Rework the current mask step, sending the wafer back through lithography;this will hopefully save the current batch.

– Take the faulty etcher offline and inform the scheduler so that future batcheswill be rerouted to other etches. This will save future batches.

Interprocess control is a critical requirement in the CSRS and is addressed inpart by the CIM Framework Specification; future enhancements to this andother specifications should further specify this form of control.

Piggyback Controller Refers to a class of controllers that are integrated with the traditional equipmentcontrol system and perform selected control functions that are generally beyondthe capability of the traditional control system. For example, at the real-timelevel, a piggyback controller running a real-time operating system and utilizinghigh speed data interface cards may utilize OEMs and Vibes data to stabilize anetch process through adjustment of power, pressure and flow equipment inputs.The equipment controller purchased with the system is still utilized to controlthe sequential operation of the tool (e.g., pumpdown, gas flow, light plasma,etc.). However, as it is not equipped to modify equipment inputs during a run,this task is accomplished by the piggyback controller.

Specifications for piggyback controllers may well be a primary use of theCSRS in the near future, as piggyback controllers generally represent elementsof next-generation controllers (see also Appendix F).

Real-Time Monitoring Real-Time Control

Generally refers to the monitoring/control of a process (through process andequipment parameters) in-situ. The frequency of the data collection variesamong applications, but is generally in the neighborhood of 1 Hertz or higher.In many cases, the determinism of the data collection is also very important(i.e., low and bounded jitter); this form of real-time control also is referred to astime-critical control frequency. Real-time control is a form of feedback control.

Real-time monitoring/control CSRS issues include volume data management,data time-stamping, system performance, and integration of third-party controlalgorithms.

Run-to-Run Control A form of discrete (as opposed to continuous) process control whereinformation such as metrology related to the quality of the process is utilizedalong with possibly a model of the process and/or equipment, and the processand/or equipment history to control the process. Control is achieved byadjusting process and/or equipment settings for the next execution of theprocess. Run-to-Run control is a form of feedback control. As such, the controlaction impacts the next execution of the process (on the next wafer or batch ofwafers). Run-to-run control in a cluster tool refers to control at each processmodule; cluster tool to cluster tool control is a form of interprocess control.

Run-to-run control is a critical requirement in the CSRS. Many of theserequirements are addressed with the APC portion of the CIM Framework.


52

APPENDIX D

Alignment with SEMATECH 300 mm Equipment Control Systems (ECS) Requirementsand International 300 mm Initiative (I300I)

There are two major requirements-gathering efforts focused on 300 mm tools: the SEMATECH300 mm ECS focus team, and the I300I effort. The following subsections present the controlsystems requirements identified by each of these efforts and describe the mapping of theserequirements to the CSRS to verify the specification’s alignment with these activities.

D.1 The SEMATECH 300 mm ECS Focus Team

SEMATECH in mid-1996 convened a 300 mm ECS Focus Team to identify and prioritize a setof user requirements for 300 mm next-generation equipment control systems. The output of thatteam is the list of requirements in the table below.

CSRS alignment with the requirements of the 300 mm team is critical. As a first step, a detailedanalysis of the requirements list should be performed and mapped into the CSRS. In theremainder of this appendix, a mapping is presented. Note that as both the 300 mm requirementslist and the CSRS are expected to evolve, this mapping also will evolve.


53

300 mm ECS Requirement CSRS Mapping (see also Table 1)

1 Data Access:

– Time-stamped sensor and actuator data

– Synchronizing with external clock

– Support HSMS or other high speed equipmentlink

– Provide means for wafer tracking down to toolload position/cassette position

– Maintain data integrity through entire usecycle.

Identified as requirements 1, 8, 10, 11, and 14. Mostrequirements are addressed through envisioned ratherthan existing standards. CSSWG should work withECS team to further these specifications. Note thatspecification of HSMS link is questionable givendirection of OBEM standard (and CORBA-compliantCIM systems). Data integrity, though implied by CSRSrequirements, is not explicitly stated. Future CSRSversions should have this requirement explicitly stated.

2 External Control of Machine State

– Externally command shutdown of singlechamber tools; shutdown each chamber ofprocess tools

– Externally command endpoint

Identified generally as requirements 8, 9, and 15, andaddressed as envisioned standards. This specificrequirement for remote control capability for tool orchamber shutdown should be explicitly stated in futureCSRS versions. The need for externally commandedendpointing is not stated as a CSRS requirement, butwill be addressed under the heading of providing aremote control capability.

3 Support of Run-to-Run Control Strategy

– Update local recipe via higher level download;capability for adjustment on a per-wafer basis;support feed forward (interprocess) andfeedback (run-to-run) control

– Recipe format for reading and editing at celland factory levels

– Process control strategies in equipmentdocumentation

Addressed to a large extent through specification ofrequirements 2, 3, 4, 5, 21, and 22, and as envisionedstandards. Requirements for recipe format for factoryand cell level read and edit, integration of third partcontrol strategies and software, and process controlstrategies for equipment documentation should beincluded in future revisions of the CSRS.

4 Auxiliary Sensors

– Ability to electrically add sensors to tools andsynchronize

– Add process and wafer state sensors to processchambers

Sensor integration at the software level is addressed inthe CSRS through specification of requirement 6 andthe SAN standard suite. Integration of sensors at theelectrical level (e.g., signal levels) should be added asa requirement in future CSRS revisions. Addressingthis requirement should cover the integration ofsensors into processing chambers.

5 Reliability, Availability and Maintainability

– Support ARAMS

– Control system MTBF 750 hours.

– Certifiable software development process

– On-line documentation (SEED)

ARAMS and SEED requirements currently asaddressed by the CSRS (requirements 15–20). Thedefinitive MTBF should be part of a reliabilityspecification (e.g., EMS99] referenced in the CSRS.The requirement and need for a document to addressthe software development process certification shouldbe included in future revisions of the CSRS.


54

D.2 The I300I Effort

The International 300 mm Initiative has been very active in 1997 defining control systemsrequirements needs for 1998 300 mm tools. The results of this effort along with a parallel effortundertaken by Japan’s 300 mm Semiconductor Technology Conference (J300) consortium aresummarized in CIM Global Joint Guidance for 300 mm Semiconductor Factories [14]. Thestated purpose of this combined effort is “...providing joint consensus guidelines for and tosemiconductor industries and silicon suppliers ...[that] are designed to integrate automationsoftware systems with other key factory capabilities to ensure that the industry fully realizespotential 300 mm productivity benefits” [14]. It is important to note that both I300I and J300plan to target these guidelines towards the purchase and configuration of 300 mm tools beginningin 1998. Thus, these guidelines can be termed a near-term, next-generation solution. It istherefore important, within the context of this CSRS document, that the requirements andsolutions of the current and near-term next-generation CSRS (Section 6) be aligned with similarI300I/J300 results. An analysis of the CIM guidelines presented in the I300I/J300 documentspecify adherence to the following SEMI Equipment Automation Software standards [3] (seeAppendix A of [14]):

• SEMI E5: SECS-II

• SEMI E30: GEM

• SEMI E37: HSMS

• SEMI E37.1: HSMS-SS (Single Session—to support GEM)

• SEMI E58: ARAMS

• SEMI E58: SECS-II Support for ARAMS

Additionally, the I300I/J300 Document specifies a GEM draft document (Document #2749)which is a GEM enhancement to support a Port Model. A review of these specifications withrespect to the CSRS specification for near-term, next-generation systems presented in Section 6,clearly indicates that the two specifications are aligned.

The I300I effort is ongoing and revisions of the 300 mm guidance document are expected. It isimportant that the CSRS document be updated to maintain alignment with this document,especially with respect to the definition of the CSRS for current and near-term, next-generationsystems.


55

APPENDIX E

Alignment with Advanced Process Control Framework

An active part of the current CIM Framework development effort is the specification of the APCFramework. The APC specification follows the paradigm of the overall CIM Framework,specifying plugable applications linked through a CORBA-compliant Object Request Broker(ORB) communication scheme (see Figure 6). The issues addressed by the APC Framework, andtheir impact on the CSRS include the following:

Issue Impact on CSRS

1 Interprocess (i.e., spanningmultiple process steps)feedforward and feedbackcontrol

This type of control is specified as factory level control in the CSRS.Future versions of the CSRS should specify this version of control moresuccinctly (requirements 2 and 4).

2 Data AcquisitionManagement/Reporting

Identified in requirements 1, 8, and 12 of the CSRS (see Table 1).

3 Capability for 3rd party softwareapplications

Identified in requirement 7 of the CSRS (see Table 1).

4 Integration with otherFramework components

The CSRS specifies the CIM Framework (and its components) as acritical element (requirements 5 and 22).

5 User interface requirements Deemed outside the scope of the CSRS by the CSSWG.

The APC focus team has made great strides in 1997 and has defined a framework-compliantstructure for an advanced process controller as shown in Figure 7. The focus of control definitionhas been at the supervisory/host level, where typically run-to-run control and potentiallyfeedforward interprocess control are implemented. Thus, the impact of the APC results in theCSRS should be significant in the levels of control above the equipment-control level. As anexample, the APC specification should be a part of the piggyback controller specification forcurrent and near-term, next-generation systems (see Section 6 and Appendix F). Because currentsolutions cannot support many of the concepts specified in the APC Framework, the current andnear-term, next-generation systems CSRS should provide a migration path from what can beachieved today, to a (future) fully APC Framework-compliant system.


56

DataCollection

Plan

ProcessPlan

DataRetrieval

Spec

ProcessModel

APC Framework

Model Predictive

Control

SPC

Run-to-Run Control

Process Modeling

Data Reduction Analysis

MES Framework

Enterprise Framework

Scheduling, Tracking, Routing, ...

Recipe Mgmt., MaterialMovement, ...

OBEM GEM/SEM

Scheduler Process FlowManager

Factory Order Process Plan

Equip. Integration Framework

Object

Request

Broker

Figure 6 The APC Framework Integrated In the CIM Framework

MachineManagement

ControlExecutor

ControlDatabase

ControlArchivePlugin

Management

PluginExecutor

ControlManager

SupervisoryController

CORBA

Figure 7 The APC Framework Advanced Process Controller


57

APPENDIX F

Applying the Control Systems Requirements Specification to Control Systems

The CSRS provides a comprehensive specification for state-of-the-art control systems in thesemiconductor manufacturing arena. As such, three important classes of applications of thespecification are envisioned:

1. Updating or retrofitting controls to current systems

2. Applying state-of-the art controls as enhancements to current systems (e.g., piggybackcontrollers)

3. Specifying controls for next-generation systems

F.1 Updating or Retrofitting Controls to Current Systems

In many semiconductor control applications, existing control elements are being replaced bystate-of-the-art control elements to improve overall equipment effectiveness (OEE). Typically,this process involves updating the equipment control system to a more modern platform tosupport applications that will improve OEE (such as fault diagnostics, real-time monitoring,run-to-run control, etc.), enhance the user interface qualities of the control system (e.g., TTY ormenu-driven to graphical interface conversion), and to support higher levels of automation(e.g., automated recipe management and download, increased data logging capabilities andvolume data management, etc.).

In this scenario, the CSRS provides utility by specifying the form, capabilities, content, andinteraction of the new control elements. It can serve as input to a purchase specification for suchcontrol systems, and can further serve as a communication aid between the control systemsupplier, integrator and user.

F.2 Enhancing Current Systems (through Piggyback Controller)

A widely utilized method for adding control system capability is through the use of piggybackcontrollers (see Appendix C). These controllers work with the existing control system and focuson a specific element of control that the current control system is incapable of supporting. Anexample of a piggyback control implementation is shown in Figure 8. Here a piggybackcontroller (i.e., the Real-Time Controller, or RTC) is utilized to provide enhanced real-timemonitoring and control to a reactive ion etch (RIE) or plasma-enhanced chemical vapordeposition (PECVD) chamber in a cluster tool. The Process Module Controller (PMC) is notreplaced, but rather enhanced with the piggyback controller. A relay system provides for transferof control between the two controllers in a way that ensures maintenance of all safety features(e.g., interlocks) of the existing PMC.

In this scenario, the CSRS provides utility by specifying the form, capabilities, content andinteraction of the elements in the piggyback controller. Additionally, it can serve to betteridentify the interaction between the piggyback controller and the existing control system. Thus,the CSRS again serves as a purchase specification, and communication aid between controlsystem supplier, integrator and user.


58

This piggyback controller adds an in situ monitoring and control capability to an existing system.Currently, a more common form of piggyback control utilization provides a run-to-run APCcapability. An example of the formulation (using the CSRS) and design of such a controller isgiven in Section F.4.

PMCRTC

(ISI AC100-C30)

PM - (RIE or PECVD)

RB

A*

B*

EndPoint Feedback Channel

RF OnA*

Endpoint On B*

KEY:

PMC Process Module Cntrlr RB Relay Bank RTC Real-Time Cntrlr

Figure 8 Example of Piggyback Controller Implementation: (Real-time ControlPiggyback Controller for a Process Control Module in a Cluster Tool)

F.3 Specifying Next-Generation Control Systems

A clear impact of the CSRS is the specification of next-generation control systems such as thosefor 300 mm systems (see Appendix D). Here the CSRS is useful in all phases of control systemsspecification, development, implementation, and test. Specifically, it can serve as a frameworkfor identifying specific user requirements; as an aid for formulating these requirements into apurchase specification; as a communications aid between control system supplier, integrator anduser; and as a system test qualification mechanism.

F.4 Example: Utilizing the CSRS to Provide a Piggyback Run-to-Run APC Capability; A CSRS for a Piggyback Controller

A very common application of APC in the enhancement of current systems is the application ofrun-to-run control through the utilization of a piggyback controller (see also Section F.2) [2, 12].The requirements of the controller are generally as follows:


59

1. The system must integrate a metrology capability that captures one or more process qualityparameters on a run-to-run basis. An example is a post-process thickness sensor that couldevaluate remaining thickness of a layer and uniformity of that layer. A second example is ametrology system that delivers an in situ “footprint,” or process/wafer parameter trace, for aprocess run, from which process and product health may be derived.

2. The process must utilize the integrated metrology and provide automated run-to-run controlprocess improvement via the automatic adjustment of recipes on the tool. The recipe inputparameters to be adjusted are determined by the control systems integrator working within theconstraints supplied by the user and the equipment.

3. The piggyback controller configuration must operate within the existing CIM and MESsystems. That is, there should be no reprogramming of the factory level CIM and MESsystems required.

4. The software solution must be reliable and maintainable and allow for integration ofthird-party software.

5. The solution must utilize existing SEMI standards wherever possible and provide a migrationpath to the envisioned long-term CSRS.

In order to achieve these requirements the following CSRS, based on the CSRS for current andnear-term next-generation solutions (Section 6), is specified.

1. The controller shall utilize GEM to communicate with the metrology and process tools.Additionally, if supported, the controller shall also utilize any applicable SEM standard.Current process and metrology system tools should support GEM. GEM provides amechanism for gathering of metrology data. It also provides a mechanism for adjusting ofrecipe parameters via equipment constant settings; this capability is not required for GEMcompliance, but is being developed as a near-term future enhancement to GEM to supportAPC. This specification addresses requirements 1, 2, and 5.

2. The internal structure of the controller shall be of a form that can migrate to an APCFramework-compliant solution. What this means is that the software structure of thecontroller should be object-oriented, should utilize CORBA or a similar objectcommunication mechanism to support communication between functional modules, andshould define a plugable capability for the functional modules (i.e., a well-defined objectoriented interface to each module). In order to support this internal structure in a GEMcommunication environment, software conversion modules or wrappers should be providedthat convert the internal CORBA communication to GEM messaging as necessary to achieverun-to-run control. This specification addresses requirements 3, 4, and 5.

3. The controller should provide a GEM pass-through capability, thereby maintainingequipment connectivity with the host, MES and factory level CIM system. The pass-throughoperation is illustrated in Figure 9. The controller communicates with the equipment,metrology system, and host in such a way so as to provide the host with an interface that isthe same as the original equipment and metrology systems interface. A specification for thisinterface is given in [15]; it defines the simulation of the equipment and metrology systemcommunication and control state models within the controller so that synchronizationbetween the equipment, metrology, and host can be maintained. This specification addressesrequirements 3 and 5.


60

The resulting specification for the piggyback system addresses all of the system requirementsidentified and is realizable with today’s technology and standards. Further, it represents thederivation of a specific CSRS utilizing the methodology defined in this document, andspecifically in Section 6.

As a final note, the piggyback solution, though representing a method for rapidly incorporatingan APC capability, is not considered a final solution for that capability. As the capability isproven it may be migrated into the tool or up into the factory control system as illustrated inFigure 10, while the piggyback controller may be retained for rapid deployment of a new APCcapability. Adherence to the CSRS in developing the piggyback controller and migrating to thefinal solution will facilitate the migration and result in a more cost-effective and reliable solution.

Tool Metrology

Factory Host

R2R Control System

Pass Through Cntrlr Pass ThroughRecipe AdvicesAlarm Actions

R2RMetrology

SECS/GEM

SECS/GEMSECS/GEM

Figure 9 Illustration of CSRS for Piggyback “Pass-Through” Operation

Tool

SECS/GEMInterface

GEM/SECSHost

In-LineMetrology

SECS/GEMInterface

AEC / APCController

SECS Interface(GEM Optional)

SECS/GEM

SECS/GEM

CORBA

InterProcessControl

Tool

Tool Controller (OBEM)

IntegratedMetrology

R2R

R2RPlug-ins

OR

Figure 10 Migration of the Piggyback Control Capability


61

APPENDIX G

Mapping CSSWG Raw Requirements to CSRS Document Requirements

In mid-1996 the CSSWG conducted a round-robin requirements gathering session in an attemptto exhaustively compile a list of semiconductor manufacturing control systems requirements. Thelarge number of raw requirements generated were then analyzed and categorized. Finally, in anattempt to make the CSRS document more concise, this categorized list was mapped to theCSRS requirements given in Table 1 of the document body.

In this appendix, the process of mapping the raw requirements to the CSRS requirement set isaddressed. Specifically, in Section G.1, the types of requirements gathered are described andselected requirements are mapped. The raw requirements are included for reference in SectionG.2.

G.1 Mapping CSSWG Requirements to the CSRS

Over 70 raw requirements were collected in the aforementioned gathering session. An analysis ofthese requirements reveals the following:

1. Many of the requirements are really directions to guide the development of the CSRS,i.e., they are requirements on CSRS development rather then on the control systemsthemselves. As an example, the requirement “Reuse existing standards—which to use—which not to use,” is a direction utilized heavily in CSRS formulation.

2. Many of the requirements are outside the scope of the CSRS. For example, the CSSWG has,in 1997, determined that user interface issues should not be part of the CSRS document.Thus, requirements such as “Support foreign language user interface,” are outside the scopeof the CSRS.

3. Many of the requirements overlap and thus can be restated as a single requirement.

The raw requirements thus may be refined into a smaller, more concise set such as the set givenin Table 1, and into CSRS document directions. Table G.1 presents a partial mapping of the rawrequirements to those of Table 1 and to CSRS directions. Note that the raw requirements foundin Subsection G.2 are referenced by number if they are found in the “AECFW Requirements(ungrouped)” section, or by their section acronym and number if they can be found under agrouping (e.g., VMO1 is the first Visibility of Machine Operation grouping requirement inSubsection G.2).


62

Table G.1: Mapping of Raw Requirements to Table 1 RequirementsSelected RawRequirement Table 1 Requirement

DPR 1: Time stamp data 1: Specification for synchronization/time stamping of data

30: Process controlmodels that can acceptand correlate in situ data

2: Real-time (in situ), run-to-run and factory level control capabilities

62: Integration of off-linemetrology

3: Specifications. for combining run-to-run and in situ control

61: Feedforward/feedbackcontrol within andbetween tools

4: Specifications. for combining run-to-run and factory level control

15. Modular, ScaleableFactories

5: Defining equipment, run-to-run, and factory-level control systems utilizing astandard object based paradigm

23: Easy to add sensors

45: The ability addsensor/equipment/etc.components to a tool andintegrate them withexisting control capabilityof the original tool

51: Need to be able tointegrate sensors fromsmall OEM companieswith new and existingtools.

6: Specification for sensor integration into the control system (models,communication protocols, etc.)

12: Need a Systematicapproach to integratingnew function

7: Specification for integration of (third-party) control algorithms at equipment andrun-to-run level (without affecting integrity of control system or tool)

28: Data display must beoptimized

8: Defining data accessibility/visibility at equipment and run-to-run control levels

RMR1: Identification oflocal and remotecapabilities

9: Specifications for remote monitoring

VMO2: Support idea ofwafer state...

10: Specifying wafer state information

VMO1: A machine stateshows exactly where theprocess and the wafer is atany time.

11: Supporting wafer driven processing

Follow-on requirementsgathering

12: Specifications for volume data management

300 mm ECS requirement 13: High speed network compliance

OBEM requirement 14: Defining a successor to SECS-II GEM that delivers higher throughput

VMO requirements 15: Specifications defining visibility of machine operations


63

Selected RawRequirement Table 1 Requirement

DPR2: Must be able tomeasure the determinismand the response time ofthe control system.

16: Deterministic performance requirements

CMR requirements 17: Configuration management requirements

ARAMS requirement 18: Specifications for equipment transition between up/down time, maintenance, etc.

ARAMS requirement 19: Specifications for equipment maintenance

TR requirements 20: Specifications for testability requirements

18: Support ProactiveAPC with Fault Detection,Prognosis, andClassification, andAdaptive process Control

21: Specifications for fault detection and end-point control

38: AECFW required by0.25 µm

22: Alignment with the APC Framework Efforts

CSSWG Direction 23: Alignment with 300 mm ECS Efforts

CSSWG Direction 24: Alignment with I300I Efforts

CSRS Direction

22: ... ability to customizestrategies withoutsoftware support56: The ability modifytool controlimplementation asengineers, withoutengineers having to writecomputer programs

... add new capabilities at the user skill level

Available as piggybackand embedded versions

Section 6 and Appendix F

Use Existing Standards(grouping)

CSRS explores all existing SEMI software automation standards

Collect Users’Requirements (grouping)

Cornerstone of CSRS development

DMR1: Data managementsupport

Requirements for volume data management and general direction of CSRS

OT2: Comprehendimproving existingequipment and newequipment...

Focus on piggyback APC as well as next-generation solutions.


64

G.2 CSSWG Raw Requirements (reference)

• Use Existing Standards

1. Reuse existing standards—which to use—which not to use.

2. Develop object-based specifications compatibility with all InternationalOrganization for Standardization (ISO) standards

3. Compatibility with all ISO standards

4. Use standard protocols for communication outside the tool such as GEM andSECS-II

5. Support the Automated Reliability Availability Maintainability Standard

6. Provide control system fault detection and tracking

7. Like ISO/Department of Defense (DOD), define a certifiable standard for thesoftware development process. Build on Software Process Improvement (SPI)work.

8. Define and use standard messaging between classes of objects e.g., CORBA

9. Standardize online documentation. Is the SEED standard adequate? Use HTML.

10. How have other industries addressed these problems?

11. Consider the question: “Will the adoption of outside standards (e.g., Microsoft)affect our standard?”

12. Look to DOD experience in specifying UI and test methodologies.

• Collect Users’ Requirements

1. Acknowledge that requirements come from both the semiconductormanufacturers and the tool suppliers.

2. Agree on a schedule and intermediate milestones of useful deliverables.

3. Follow a formal process for collecting requirements, i.e., establish therequirement before beginning design, requirements of both end users andsuppliers) (67)

4. Structure requirements in layers: generic equipment-type, manufacturer-specific.

5. Know that a way to get the detail of what the control system does is to use the“rapid requirements process” employed at TI (Richard Beaver).

6. Focus on requirements of what the control system does.

7. Define reliability requirements of control systems.

8. Develop a roadmap to achieve requirements for run-to-run and real time control.

9. Produce a list of controller features desired by the end users. Rank-order thecontrol functionalities on a roadmap. (12)

10. Include foreign end users in collecting the control requirements (10).

11. For each type process, have the user define the type of data to collect.

12. Develop a second document that contains a common list of user and supplierrequirements (8).

13. Define cost target and perform cost/benefits analysis.


65

• User Interface Requirements

1. Include requirements for the user interface (man-machine interface) in therequirements.

2. Support foreign language user interface.

3. How changeable should a UI be, and by whom?

• Third-Party Algorithm Support

1. Allow the user to implement control algorithms without damaging the tool oraffecting the integrity of the control system.

2. Address integration of third-party control algorithms with the control system.

3. Use third-party fault detection/classification and advanced process controlalgorithms without need for writing more code.

4. Define a firewall behind which any third-party may not make software changes.

5. Define a “control language” for process engineers’ use.

6. Support process model development.

• Sensor Integration

1. Develop a consensus on common protocols for sensor bus (most useful to sensorproviders).

2. Develop guidelines for integrating new sensors.

3. Define electrical interface specifications. Define analog levels, impedance, etc.,for input/output (I/O) interfaces.

4. Define sensor and subassembly interface and interactions.

5. Define the functionality, functional boundaries, and interfaces between the“black boxes” in the control system.

• Testability Requirements

1. Testability: Establish guidelines to achieve 100% test coverage for softwareupdates (33).

2. Include testing of user interfaces.

3. Support equipment maintenance.

4. Provide a way to verify the control system functionality, e.g., a simulator to testthat the control system meets specifications.

5. Test the whole system. Test software independently and perform a combined testof the software “moving the hardware.”

6. Have a Control System Performance Specification and a process for certificationto that specification.

7. Perform functional testing at both user and supplier locations.

8. Determine how the user can write specifications. Describe what he/she should beable to change. Determine how to test ease of use in making such changes.


66

9. Define a common set of diagnostics (for equipment or equipment control?4).

• Remote Monitoring Requirements

1. Identify local and remote capabilities (28, 32).

2. Be able to view control system remotely.

3. Provide remote monitoring from engineer’s office (28).

• Visibility of Machine Operation

1. A machine state should show exactly where the process and the wafer are at anytime.

2. Support idea of wafer state, e.g., current etch rate, film thickness, etc.

• Configuration Management Requirements

1. Define requirements for control software, i.e., version level and change control.

2. Perform software maintenance, including remote upgrade and configurationmanagement.

• Deterministic Performance Requirements

1. Provide time stamp data.

2. Be able to measure the determinism and the response time of the controlsystem (68).

3. Provide real-time monitoring and display of “activity bandwidth” (percentage ofsystem loading). Ensure that system never gets overloaded.

4. Be able to collect data deterministically (equal time intervals) (65).

• Data Management Requirements

1. Data management support

2. Standard support for traceability (of what?5)

3. Standard event log (related to ARAMS E-0 standard—#56)

4. Data integrity—ensure the database information is current and accurate

• Other Topics

1. Comprehend improving existing equipment and new equipment. Think abouthow legacy tools can be improved along the way.

2. Define locations on the tool where the addition (integration) of sensors wouldimprove yield.

4 NOTE TO AUTHOR: Does this really belong in this finished document?5 NOTE TO AUTHOR: should this question be part of the document?


67

• AECFW “Raw” Requirements:

1. Standard information and behavior applicable to the cluster application objectsand services

2. Communication services for the implementation of a functional cluster controlsystem

3. A runtime process control architecture allowing modification of the processingenvironment to accomplish feedforward control

4. An architecture that “makes the machine a part of the factory”

5. AECFW must fit with or into the SCAFW

6. Support a common core of widely accepted technology

7. Be compatible with existing, commercially available control systems.

8. Support sufficient flexible optimization, when economically related options areavailable

9. Be the basis for higher software reliability

10. Transfer of technology must be facilitated

11. Better software integration capability

12. A systematic approach for integrating new function

13. Virtual factory to run in parallel with the real factory

14. Manufacturing systems with completely integrated control and simulationcapability

15. Modular, scaleable factories

16. “Responsible agent” software

17. Must incorporate “need-based” PM strategy

18. Support proactive APC with fault detection, prognosis, and classification, andadaptive process control

19. Support “input-to-output” model as the basis for controllability

20. User-friendly interfaces

21. Easy to use a wide range of model types

22. Wide range of control strategies and the ability to customize strategies withoutsoftware support

23. Easy-to-add sensors

24. Available as piggyback and embedded versions

25. Easy connectivity to the factory

26. Provides data collection capability to support process characterization design ofexperiments (DOE)

27. Standard communication protocol for sensors

28. Data display must be optimized

29. Process control system must support merging of tool state data and sensor data

30. Process control models that can accept and correlate in situ data.


68

31. Need ability to apply system identification techniques to build simple linearmodels

32. Merge laboratory data with a process and/or control model online

33. Must allow for a solution for the “data skew” problem

34. Support the translation of a process and/or control model into an operationalform such that the original model is enforced (especially when the originalmodel is changed)

35. Integrity of data must be enforced from the time it is captured by the system, andat ever, access by all users

36. Control strategy documentation must be readily available

37. Must be “possible to construct a working controller system from existingcommercial off-the-shelf (COTS) products without having to create anycomponent parts”

38. AECFW required for 0.25 µm

39. Advanced equipment process control and statistical process control (SPC) mustcoexist

40. Commonality, provision for tool and equipment maintenance, andinteroperabillity of control system components

41. Hardware compliant with standards, such as MESC

42. Tools available to the process engineer should have the same sort of relationshipto the tool/equipment control system as test equipment has by having theIEEE 488 as a standard equipment interface

43. Comprehensive logistics tracking with download of required recipes, at the timethey are required, that supports feedforward/feedback process control—with ruleenforcement, and in real time (e.g., metrology to the RIE process).

44. User capability to “drag and drop” data, algorithms, modifications, etc., via a“Windows-like” interface.

45. Ability add sensor/equipment/etc. Components to a tool and integrate them withexisting control capability of the original tool.

46. “Real time tool and process control”

47. Smart, real-time schedule optimization that takes into account disturbances asthey occur

48. Capability to process until “done,” with the ability to take in situ tests intoaccount and ability to continue the process if necessary, such that the requiredresults are obtained

49. Ability for the user to define/modify an application, such that the user can “getin between the cracks” of the tool control system

50. Capability to interchange both hardware and software components of tools andtool control systems such that the user can achieve the application desired bythat individual—with the pieces available from multiple vendors

51. Need to be able to integrate sensors from small OEM companies with new andexisting tools


69

52. Need support for changing tool instrumentation as new requirements surface

53. Support for customizing off-the-shelf sensors

54. Support a set of data reduction techniques

55. Need to be able to upgrade tool for changing requirements, on an evolutionarybasis.

56. Ability to modify tool control implementation as engineers, without engineershaving to write computer programs

57. Better “real-time tool and process control”

58. Capability to design/structure display screens to satisfy local user requirements(subject to local management of style and content)

59. Support for DOE model development integrated with experimentimplementation, and implementation of the results on the plant floor.

60. Model-driven APC (changes to the model enforced on the plant floor)

61. Feedforward/feedback control within and between tools.

62. Integration of offline metrology..

63. In situ SPC with operator interface at the tool

64. Integrate external applications with tool control application

65. Ability to determine the “state-of-the-machine” on demand (includinginstrumentation states)

66. System-supported trend detection

67. Confidence in the data acquired for secondary use

68. Capability to selectively acquire data (source, quantity, and frequency) withsupporting semantics

69. Need the tool control system to accept data that will optimize control targets andcontrol strategy

70. System-supported, user-accessible, short-term tool history data

71. System and demand check-pointing of tool and job status

SEMATECH Technology Transfer2706 Montopolis Drive

Austin, TX 78741

http://www.sematech.org