Purposedownloads.semi.org/.../$FILE/5716.docx · Web viewfault prediction (or prognosis) (FP) — the technique of monitoring and analyzing variations in process data to predict anomalies

Background Statement for SEMI Draft Document 5716

Revision to SEMI E133, SPECIFICATION FOR AUTOMATED PROCESS CONTROL SYSTEMS INTERFACE

and

SEMI E133.1, PROVISIONAL SPECIFICATION FOR XML MESSAGING FOR PROCESS CONTROL SYSTEMS (PCS)

NOTICE: This Background Statement is not part of the balloted item. It is provided solely to assist the recipient in reaching an informed decision based on the rationale of the activity that preceded the creation of this ballot.

NOTICE: For each Reject Vote, the Voter shall provide text or other supportive material indicating the reason(s) for disapproval (i.e., Negative[s]), referenced to the applicable section(s) and/or paragraph(s), to accompany the vote.

NOTICE: Recipients of this ballot are invited to submit, with their Comments, notification of any relevant patented technology or copyrighted items of which they are aware and to provide supporting documentation. In this context, ‘patented technology’ is defined as technology for which a patent has been issued or has been applied for. In the latter case, only publicly available information on the contents of the patent application is to be provided.

NOTICE: Additions are indicated by underline and deletions are indicated by strikethrough.

PLEASE NOTE: This ballot contains a proposal for a revision to an existing standard.

Purpose

Adjustments are needed to existing E133 and E133.1 standards content to better align with the SEMI XML style guidelines document [SEMI E121-0305 (reapproved 1111): Guide for Style and Usage of XML for Semiconductor Manufacturing Applications]. Technical changes are needed to clarify the implementation of the PCS analysis engine.

SEMI E133.1 still contains the term “Provisional” that is no longer used in SEMI Standards.

Background

E133 “Specification for Automated Process Control Systems Interface” Standard includes a “dot” standard, E133.1, which is a provisional specification for the implementation of the E133 standard utilizing XML. In reviewing these specifications issues of alignment with the SEMI XML specification were identified. An update to the standard is needed to address these issues and improve the overall XML and associated UML for improved alignment and usability.

Impact

This ballot will only impact the standards E133 and E133.1.

DRAFT

Document Number:

This ballot will be a major revision to E133 and E133.1.

Proposal

This ballot proposes changes to E133 and E133.1.

The ballot includes a Complementary File: the XML Schema file.

This ballot will propose the following changes:

E133: Changes to E133 to improve alignment with the aforementioned XML guidelines document, and maintain alignment between E133 and E133.1.

E133.1: Enhancements to XML specification. Adjustments will be made to existing E133 and E133.1 standards content to better align with the XML guidelines document, as necessary. Technical changes will be made to clarify the implementation of the PCS analysis engine type.

E133.1: Changes to the schema and addition of Complementary file, the XML Schema file: E133-1-Vmmyy-PCSAE-Schema.xsd

E133.1: Removal of “Provisional”.

E133 and E133.1: Changes to clarify the implementation of the PCS analysis engine and improve usability.

SEMI Editorial staff will provide at minimum the following editorial support of these documents:

The SEMI editorial staff shall correct occurrences of “mmyy” in the document and in the Complementary file as listed below with the standard numerical designation (Esss) and publication date (mm – month, yy – year) of the specification. For example, if the publication date is August 2016, the “mmyy” becomes “0816”. This includes the following:

o Update all occurrences of “E133-1-Vmmyy-PCSAE-Schema.xsd”

o Update the name of the Complementary File “Esss-mmyy-SECSIIMessageNotation-Schema.xsd”

o Insert the SEMI standard designation in the Related Information Notice.

o Update all references to “Esss”, such as in the Appendix.

A summary of some of the more significant changes being proposed is provided in the remainder of this background section. This is followed by the ballot.

Background Discussion On a Portion of the Proposed Changes

NOTE: This section of the document is not part of the ballot. It is part of the ballot background section.

Introduction

This is a Draft Document of the SEMI International Standards program. No material on this page is to be construed as an official or adopted Standard or Safety Guideline. Permission is granted to reproduce and/or distribute this document, in whole or in part, only within the scope of SEMI International Standards committee (document development) activity. All other reproduction and/or distribution without the prior written consent of SEMI is prohibited.

Page 2 Doc. jn l SEMI

SEMI

673 S. Milpitas Blvd.

Milpitas, CA 95035-5446

Phone: 408.943.6900

DRAFT

Document Number:

The Analysis Engine data structure model for a complete message associated with a PCS job provided in E133 has been modified to

address a number of issues of clarity and alignment as mentioned above. The following is the new data structure model. The discussion section that follows provides insight into some of the issues that are addressed with this modification.

AE Data Structure Model for a Complete Message Associated with a PCS Job

Discussion

• ISSUE: Multiple similar elements in AnalysisEngineDataSet

– Currently

• AnalysisEngineDataSet defines Globals, AnalysisParameters, CalculatedOutputs, LogMessages, ModuleData, ProcessData, and SubstrateData all effectively have the same structure of a class with two members of DataItemType (Context and Data)

– Challenge



SEMI



Phone: 408.943.6900

DRAFT

Document Number:

• Does not follow XML TF standards

• Create multiple duplicate classes where the only item that is different is the class name

• Forces implementations to branch on the existence of a member as opposed to the data of a member

– Solution (Changes to E133 and E133.1)

• Create a standard DataCollectionType that has 3 elements

• Context and Data of type DataItemType

• BinCategory as an enumerated list indicating the type of data

• ISSUE: Status Element Ambiguity

– Currently

• Status is member of AnalysisEngineDataSet

• This provides an overall status for the AnalysisEngineDataSet

– Challenge

• The AnalysisEngineDataSet contains a list of PCSAETargets

• Each PCSAETargets could succeed or fail and need to convey information to the caller

• In the case of more than one target the way to convey multiple status messages is ambiguous

– Solution

• Move the status message to the PCSAETarget class

• This way each function that processes data has its own unique status

• ISSUE: PCSAETargets Ordering

– Currently



SEMI



Phone: 408.943.6900

DRAFT

Document Number:

• PCSAETargets is an ordered list of PCSAETarget

– Challenge

• The order in which the PCSAETarget in PCSAETargets should be invoked is ambiguous

• Left to right, right to left

• Order may not be preserved throughout calling chain

• Should a PCSAETarget be moved to the end once executed

– Solution

• Create an AEOrder element to PCSAETargetType to indicate what order the PCSAETarget should execute

• This also allows the PCSAETarget determine if the prior PCSAETarget has completed by checking its Status object

• ISSUE: PCSAETargetType Multiple Algorithm Support

– Currently

• PCSAETargetType contains AEType which specifies which type of algorithm is being invoked PCS, R2R, FDD, FCC, FPP, or SPC

– Challenge

• PCSAETargetType does not support different algorithms within a AEType

• Therefore a PCSAE service can only have one type of each type of algorithm

• Ex. an implementation would need a separate service for each WECO rule

– Solution

• Add an AEAlgorithm element to PCSAETargetType to allow selection of different algorithms within a specified PCSAETargetType

• ISSUE: PCSAETargetType Parameter Support

– Currently



SEMI



Phone: 408.943.6900

DRAFT

Document Number:

• PCSAETargetType contains Extension which is a freeform data element

– Challenge

• Extension as a freeform data element is difficult to programmatically predict and support

• The service code needs to handle all possible instantiations of Extension

– Solution

• Convert Extension to a DataItemType to give it the common Name/Value structure

• ISSUE: PCSAETargetType Multiple Instruction Support

– Currently

• PCSAETargetType contains a list of actions to perform, Instructions

– Challenge

• This is only a list of actions with no context or parameters to act on and no defined order of execution

• Ex. running the same algorithm 3 times with different sets of parameter/limits would be difficult to specify

– Solution

• Create a InstructionType class with members Instruction, Order, Extension and Status

• Convert Instructions to 1-n of InstructionType

• Note it is up to the implementation of PCSAETargetType to consolidate the individual InstructionType statuses

• ISSUE: StatusElementType Output Parameter Support

– Currently

• StatusElementType contains Extension which is a freeform data element

– ChallengeThis is a Draft Document of the SEMI International Standards program. No material on this page is to be construed as an official or adopted Standard or Safety Guideline. Permission is granted to reproduce and/or distribute this document, in whole or in part, only within the scope of SEMI International Standards committee (document development) activity. All other reproduction and/or distribution without the prior written consent of SEMI is prohibited.


SEMI



Phone: 408.943.6900

DRAFT

Document Number:

• Extension as a freeform data element is difficult to programmatically predict and

support

• The service and client code need to handle all possible instantiations of Extension

– Solution

• Convert Extension to a DataItemType to give it the common Name/Value structure



SEMI



Phone: 408.943.6900

DRAFT

Document Number:

The ballot begins on the next page and includes an attached “.XSD” file

The ballot results will be reviewed and adjudicated at the meetings indicated in the table below. Check www.semi.org/standards under Standards Calendar for the latest update.

Review and Adjudication InformationTask Force Review Committee Adjudication

Group: PCS Task Force Information and Control NA TC Chapter

Date: July 10, 2017 July 12, 2017

Time & Time zone: 15:00 – 17:00 Pacific Time 8:00 – 14:00 Pacific Time

Location: Marriott Marquis Hotel Marriott Marquis Hotel

City, State/Country:

San Francisco, CA/USA San Francisco, CA/USA

Leader(s): James Moyne (University of Michigan)

Chris Maloney (Intel)

Brian Rubow (Cimetrix)

Jack Ghiselli (Ghiselli Consulting)

James Moyne (University of Michigan)

Standards Staff: Inna Skvortsova (SEMI)

[email protected]

Inna Skvortsova (SEMI)

[email protected]

This meeting’s details are subject to change, and additional review sessions may be scheduled if necessary. Contact the task force leaders or Standards staff for confirmation.

Telephone and web information will be distributed to interested parties as the meeting date approaches. If you will not be able to attend these meetings in person but would like to participate by telephone/web, please contact Standards staff.



SEMI



Phone: 408.943.6900

http://www.semi.org/standards

DRAFT

Document Number:

SEMI Draft Document 5716

Revision to SEMI E133, SPECIFICATION FOR AUTOMATED PROCESS CONTROL SYSTEMS INTERFACE

and

SEMI E133.1, PROVISIONAL SPECIFICATION FOR XML MESSAGING FOR PROCESS CONTROL SYSTEMS (PCS)

SEMI E133-1014

SPECIFICATION FOR AUTOMATED PROCESS CONTROL SYSTEMS INTERFACE

This Standard was technically approved by the Information & Control Global Technical Committee. This edition was approved for publication by the global Audits and Reviews Subcommittee on May 12, 2014. Available at www.semiviews.org and www.semi.org in October 2014; originally published March 2004; previously published February 2012.

1 Purpose

1.1 In order to more efficiently facilitate the integration of process control systems (PCS) such as run-to-run (R2R) control, fault detection (FD), fault classification (FC), fault prediction (FP), statistical process control (SPC), etc. into current and future fabs, there is a need to define interfaces for PCS that enable them to interact effectively and share data (1) among themselves and (2) with the other interdependent factory systems (including equipment data collection). This Standard is intended for use by equipment suppliers, semiconductor manufacturers, equipment subsystem suppliers and control system suppliers who will utilize the PCS standards in future developed products.

2 Scope

2.1 This Standard focuses on defining PCS capabilities, functional groups (FGs), and FG interfaces. The Standard is structured so that new FGs can be added to the Standard through future balloting. The components in this document include:

Definitions of key terms and concepts pertinent to this domain,

Description of the specification conventions used,

Identification of the major FGs within the scope of PCS,

Description of the capabilities expected in each FG (required and optional), and

Definition of interfaces for these FGs, including:

Data that is available across these interfaces. This includes the interface data descriptions (inputs and outputs). Future enhancements to this Specification will include detailed data structures in the form of inheritance and aggregation models that are common to all PCS FGs, as well as specific models for each,

Services supported and Interface behavior assumed, and

Description of an approach for compliance verification testing.



SEMI



Phone: 408.943.6900

DRAFT

Document Number:

2.2 The specific format and protocol implementation of these interface specifications, which are technology specific, will be delineated in supporting

‘dot’ specifications to this Standard. As an example a possible format is eXtensible markup language (XML) (which would include data type definitions and metamodel schemas).

2.3 In addition to the information embodied in this Standard, the Standard describes a validation process to identify and address real implementation issues as early as possible.

NOTICE: SEMI Standards and Safety Guidelines do not purport to address all safety issues associated with their use. It is the responsibility of the users of the Documents to establish appropriate safety and health practices, and determine the applicability of regulatory or other limitations prior to use.

3 Limitations

3.1 The proposed PCS standards will not focus on:

Low-level communication mechanisms (e.g., hardware connection schemes, transport layer software, etc.) between PCS FGs,

Methodology for implementing actual equipment or factory level control strategies,

Specifying internal structure or implementation methods of PCS FGs,

Capabilities of complementary applications (recipe management, data collection, engineering analysis, data storage, scheduling, change control, …),

The management of information and collaboration between FGs. This is left to implementation,

Communications within equipment or within factory systems,

Determination of the proper control algorithm, model, or runtime selectable behavior. It is optional for a PCS function to contain ‘context matching’ (CM),

The creation and management of PCS jobs, or

Defining test procedures required for validating the Standard.

4 Referenced Standards and Documents

4.1 SEMI Standards and Safety Guidelines

SEMI E81 — Provisional Specification for CIM Framework Domain Architecture

SEMI E121 — Guide for Style and Usage of XML for Semiconductor Manufacturing Applications

SEMI E125 — Specification for Equipment Self -Description (ESDEQSD)

SEMI E134 — Specification for Data Collection Management

SEMI E148 — Specification for Time Synchronization and Definition of the TS-Clock Object

4.2 IEC Standards1

IEC 61158-5 — Digital Data Communications for Measurement and Control – Fieldbus for Use in Industrial Control Systems – Part 5: Application Layer Service Definition

4.3 [4.2 ] ISO Standards2

1 International Electrotechnical Commission, 3 rue de Varembé, Case Postale 131, CH-1211 Geneva 20, Switzerland; Telephone: 41.22.919.02.11, Fax: 41.22.919.03.00, http://www.iec.ch2 International Organization for Standardization, ISO Central Secretariat, 1, ch. de la Voie-Creuse, CP 56, CH-1211 Geneva 20, Switzerland; Telephone: 41.22.749.01.11, Fax: 41.22.733.34.30, http://www.iso.orgThis is a Draft Document of the SEMI International Standards program. No material on this page is to be construed as an official or adopted Standard or Safety Guideline. Permission is granted to reproduce and/or distribute this document, in whole or in part, only within the scope of SEMI International Standards committee (document development) activity. All other reproduction and/or distribution without the prior written consent of SEMI is prohibited.


SEMI



Phone: 408.943.6900

http://www.iso.org/

http://www.iec.ch/

DRAFT

Document Number:

ISO 8601 — Data Elements and Interchange Formats – Information Interchange – Representation of Dates and Times

4.4 [4.3 ] Other Documents

SEMATECH — Equipment Engineering Capabilities (EEC) Guidelines (Phase 2.0), Version 2.5 (July 2002)3

Rumbaugh, James, Jacobson, Ivar, and Booch, Grady “The Unified Modeling Language Reference Manual.” Addison Wesley Professional, 1999.

Booch, Grady, Rumbaugh, James, and Jacobson, Ivar “The Unified Modeling Language User Guide.” Addison Wesley Professional, 1999.

Rumbaugh, James, et al. “Object-Oriented Modeling and Design.” Prentice Hall, Englewood Cliffs, NJ (1991).

NOTICE: Unless otherwise indicated, all documents cited shall be the latest published versions.

5 Terminology

5.1 Abbreviations and Acronyms

5.1.1 AE — analysis engine

5.1.2 APC — advanced process control

5.1.3 CM — context matching

5.1.4 FC — fault classification

5.1.5 FD — fault detection

5.1.6 FDC — fault detection and classification

5.1.7 FG — functional group

5.1.8 FP — fault prediction (or prognosis)

5.1.9 PCS — process control system

5.1.10 PCS job — process control system job

5.1.11 R2R — run-to-run

5.1.12 SPC — statistical process control

5.1.13 W2W — wafer-to-wafer

5.1.14 XML — eXtensible markup language

5.2 Definitions

5.2.1 advanced process control (APC)4 — the manufacturing discipline for applying control strategies and/or employing analysis and computation mechanisms to recommend optimized machine settings and detect faults and determine their cause.

5.2.2 analysis engine (AE) — a process that utilizes data and possibly operational instructions to produce a response. In the context of this Standard, this term is used to encompass the characteristics common to all PCS functional groups.

3 SEMATECH, 257 Fuller Road, Suite 2200, Albany, NY 12203, USA; Telephone: 518.649.1000, http://www.sematech.org4 APC and PCS terms are used interchangeably in some companies. Both can be seen as the umbrella of components for process control.This is a Draft Document of the SEMI International Standards program. No material on this page is to be construed as an official or adopted Standard or Safety Guideline. Permission is granted to reproduce and/or distribute this document, in whole or in part, only within the scope of SEMI International Standards committee (document development) activity. All other reproduction and/or distribution without the prior written consent of SEMI is prohibited.


SEMI



Phone: 408.943.6900

http://www.sematech.org/

DRAFT

Document Number:

5.2.3 context — a series of attributes that uniquely identifies a manufacturing entity (e.g., wafer, lot, module, tool, reticle) and its status in the manufacturing

operation.

5.2.4 context matching (CM) — the process of comparing and matching the values of a set of attributes that represent the state of a system (e.g., process, product and equipment) to a set of stored or computed values. This is usually done so that a unique action can be specified by the CM system.

5.2.5 fault classification (FC) — the technique of determining the cause of a fault once it has been detected.

5.2.6 fault detection (FD) — the technique of monitoring and analyzing variations in tool and/or process data to detect anomalies. FD includes both univariate and multivariate statistical analysis techniques.

5.2.7 fault detection and classification (FDC) — combination of FD and FC.

5.2.8 fault prediction (or prognosis) (FP) — the technique of monitoring and analyzing variations in process data to predict anomalies.

5.2.9 functional group (FG) — a collection of closely related software capabilities that one would expect to be provided as an integrated product.

5.2.10 process control system (PCS)3 — a system capable of performing process control, which includes one or more of R2R control, FD, FC, FP, SPC, or any future process control functionality defined in this Standard for a PCS functional group.

5.2.11 process control system job (PCS job) — a unit of work that could be tracked and have data associated with it. In the context of this Standard a PCS job is associated with a unit of work that a PCS AE performs; a unique identifier such as an ID number is often utilized to track the PCS job.

5.2.12 run-to-run (R2R) control — the technique of modifying recipe parameters or the selection of control parameters between runs to improve processing performance. A ‘run’ can be a batch, lot, or an individual wafer.

5.2.13 statistical process control (SPC) — the technique of using statistical methods to analyze process or product metrics to take appropriate actions to achieve and maintain a state of statistical control and continuously improve the process capability.

5.2.14 wafer-to-wafer (W2W) control — a form of R2R control in which a ‘run’ is the processing of a single wafer. This is differentiated from ‘wafer level control’ in which the recipe may be determined for multiple individual wafers before processing begins, but not necessarily modified from wafer to wafer; for example, between wafers.

6 Background

6.1 With the development of PCS applications at the factory level and inside the equipment, it is now apparent that the lack of interface standards for these applications has inhibited widespread adoption of process control at the factory level. Moreover, adding process control and integrated metrology capabilities inside the tool requires the ability for the factory level applications to collaborate with tool level applications.

7 Conventions

7.1 This section defines conventions followed in this Document.

7.2 Object Modeling

7.2.1 Unified Modeling Language (UML) — This Specification uses UML notation for all class diagrams and for object diagrams provided as examples. No other types of diagrams are used in this Specification.

7.2.2 UML class diagrams have clearly defined meanings and are a part of this Specification. Detail contained in these diagrams is not always repeated in the text.This is a Draft Document of the SEMI International Standards program. No material on this page is to be construed as an official or adopted Standard or Safety Guideline. Permission is granted to reproduce and/or distribute this document, in whole or in part, only within the scope of SEMI International Standards committee (document development) activity. All other reproduction and/or distribution without the prior written consent of SEMI is prohibited.


SEMI



Phone: 408.943.6900

DRAFT

Document Number:

7.2.3 Class Diagrams — UML Class Charts.

7.2.4 Name of a Class — The text capitalizes the beginning of class names.

7.2.5 Abstract and Concrete Classes — Each class is specified as Abstract or Concrete. Abstract classes are not directly implemented. In this Specification ‘implemented’ means represented to the factory through the communications interface. All classes defined as concrete may be directly implemented. This Specification does not attempt to define equipment control system implementation. In UML class diagrams, abstract class names are shown in italics.

7.2.6 Class Attribute Definition — The attributes of a class are defined in table format as illustrated in the table below. Note that the ‘+’ sign in front of attributes in UML class diagrams indicates ‘public’ attributes. All attributes defined in this Specification are public.

Table 1 Attribute Table Format

Attribute Name Definition Access Reqd Form

RO, RW, or NA Y, N or NC See list below.

7.2.6.1 Access — Attributes may be settable (ReadWrite or RW) or not settable (ReadOnly or RO) through the interface services. If the attribute refers to a component of a message (e.g., that is communicated to/from a PCS analysis engine [AE]), the concept of access does not apply or is not specified in this standard and ‘Not Applicable’ (NA) is used in the Access field.

[7.2.6.2 ] Reqd — Is this attribute required? Y – Yes, or N – No, or C—Conditional. If the attribute is conditional, terms of conditionality are specified.

7.2.6.2 [7.2.6.3 ] Form — Defines the data type of the attribute. Data types specified in the PCS specification are described in the subsections that follow. Data types in this Specification are high-level definitions and should be mapped to the data types of a specific technology as appropriate. Extensions to the PCS interface specifications are not limited to the list of data types defined in this Specification. See the definition of ‘form’ in the SEMI International Standards Compilation of Terms for other form values commonly used in SEMI Documents.

7.2.6.3 [7.2.6.4 ] Constraints

7.2.6.3.1 [7.2.6.4.1 ] Constraints in UML are shown with dotted lines, typically with a note attached to explain the constraint. Constraints shown in this way tend to clutter large UML diagrams. Therefore, in this Specification, constraints are shown only on the diagrams focusing on individual classes.

7.2.7 UML Associations

7.2.7.1 The mechanism used for representing associations in UML between classes is implementation dependent. This Document is abstract in nature, and does not specify or imply any such mechanism. Any adjunct standard that provides an implementation of this Specification must include a description of the mechanism used for representing UML associations used in this Document.

7.2.8 Class Association Table — This table provides an example of the tables used to list and describe associations between classes defined in this Specification.



SEMI



Phone: 408.943.6900

DRAFT

Document Number:

Table 2 Association Table Format

Association Role Name Role Definition Comments

7.2.8.1 Association Role Name — The name of the association role being defined.

7.2.8.2 Role Definition — Describes the function or purpose of the association.

7.2.8.3 Comments — Any additional comments or notes regarding the association.

7.3 Data Types

7.3.1 The following data types at minimum may be used in this Specification to describe the form of an attribute or other similar high level definitions. Note that extensions to the PCS interface specifications are not limited to the list of data types defined in this Specification.

Any — The format may be any of the others listed in this section. Format is determined by the implementation.

Binary — A sequence of bytes that may have any value. Binary values are sometimes called ‘unformatted’ because their structure is not apparent.

Boolean — Takes the value of ‘true’ or ‘false.’

Checksum — A checksum value calculated on a specific stream of data using a specific method of calculation.

Enumeration — A format that allows a specified list of possible values. In this Document, these values are represented as text strings, but may be implemented differently (e.g., as integers that correspond to the named values).

Sequence— An ordered set of related elements that are usually of the same type.

Status — The Status type is a structure that contains information about whether or not an error that has occurred in a transmission and information on the type of error. The form of the structure is given in § 9.

String —An ordered sequence of characters. Limitations on length are left to the implementation technology unless otherwise specified in this Document. Strings are recommended to be implemented as UTF-8.

Integer(int) — A numeric value, Integers are always whole numbers. The form and number of bytes is left to the implementation definition.

List of xxx — An item that can hold multiple instances of a specified type (where xxx is the data type).

Real — A numeric value that may represent any whole or fractional number. The form and number of bytes is left to the implementation definition.

Text — A text string.Text — A string. Limitations on length are left to the implementation technology unless otherwise specified in this Document. Strings are recommended to be implemented as UTF-8.

Time — Refer to SEMI E148.

Time — Representation of the date and time of the occurrence of interest. The structure and form of items of this type is left to the implementation.

[7.4 ] Service Message Representation

7.3.2 [7.4.1 ] Service Resource Definition



SEMI



Phone: 408.943.6900

DRAFT

Document Number:

[7.4.1.1 ] The service resource definition table defines the specific set of messages for a given service group as shown in the following table Table 3:

[Table 3] Service Resource Definitions Table Format

Service Reqd Type Description

Service name Y/N N or R The intent of the service.

7.3.2.1 [7.4.1.2 ] Reqd can be Yes (Y) or No (N). Type can be either Notification (N) or Request (R). A notification service consists of messages initiated by the service provider. No response is expected. A request service consists of a request message initiated by the service user which generally asks for data or for an operation to be performed, and a related response message returned by the service provider.

7.3.3 [7.4.2 ] Service Parameter Definition

[7.4.2.1 ] The service parameter definition table defines parameter detail for each service in which parameters are explicitly specified, as shown in the following table Table 4:

[Table 4] Service Parameter Definitions Table Format

Parameter Request Response Form Description

Service parameter name (see below) (see below) Data type The intent of the parameter.

7.3.3.1 [7.4.2.2 ] The Request and Response entries can take on the following values:

M Mandatory Parameter – Must be given a valid value.

C Conditional Parameter – May be defined in some circumstances and undefined in others. Whether a value is given may be completely optional or may depend on the value of the other parameter.

- The parameter is not used.

= The entries M and C in the response can be modified with (=) to indicate that the value in the response must match the request.

7.4 [7.5 ] Behavior Representation

7.4.1 [7.5.1 ] General Behavior— Narrative is used to describe behavior that could include sequence and state behavior. Other mechanisms such as flow diagrams may be used to describe message sequences.

7.4.2 Sequence Behavior — Where appropriate, this document uses themay also use Harel State Chart notation to describe the dynamic behavior of the AEs. An overview of this notation is presented in an Appendix of SEMI E30. The formal definition of this notation is presented in Science of Computer Programming 8, Statecharts: A Visual Formalism for Complex Systems, by D. Harel, 1987.

[7.5.2 ] State Behavior — Where appropriate, transition tables aremay also be provided in conjunction with the state diagrams to explicitly describe the nature of each state transition. Each transition table contains columns for transition #, ‘Previous State,’ ‘Trigger,’ ‘New State,’ ‘Actions,’ and ‘Comments.’ The trigger for the action occurs while in the ‘Previous State.’ The “Actions” include a combination of: (1) actions taken upon exit of the ‘Previous State,’ (2) Actions taken upon entry to the ‘New State,’ and (3) actions taken which are most closely associated with the transition. No differentiation is made.This is a Draft Document of the SEMI International Standards program. No material on this page is to be construed as an official or adopted Standard or Safety Guideline. Permission is granted to reproduce and/or distribute this document, in whole or in part, only within the scope of SEMI International Standards committee (document development) activity. All other reproduction and/or distribution without the prior written consent of SEMI is prohibited.


SEMI



Phone: 408.943.6900

DRAFT

Document Number:

8 Overview

8.1 Using the simple definition of a FG given in the terminology section, the initial set of PCS FGs has been identified. To identify the proper scope (and therefore the boundaries) for these groups, the following criteria are applied to test whether or not a given set of capabilities constitutes a valid PCS FG. Specifically, a FG should satisfy one or more of the following requirements:

Support a coherent set of tasks

Share common set of data and must use it under similar constraints (performance, retention, etc.)

Internal objects are tightly coupled

Legacy implementation/integration constraints exist (e.g., the capabilities are inseparable because an external system must interact with them as an integrated whole)

Strong associations exist in the market (i.e., one would expect these capabilities to be provided as an integrated product)

8.2 Based on these criteria, and the stated implementation priorities of the semiconductor manufacturers and suppliers involved on the task force, the following initial PCS FGs have been identified:

R2R control

FD

FC

FP

SPC

8.3 R2R control includes W2W control. In this case a ‘run’ is the processing of a single wafer.

8.4 Note that it is understood that other PCS FGs can be added as needed. Future versions of the document will describe procedures for adding a new group.

8.5 The aforementioned groups can be implemented at the tool or factory level or both. As a requirement, FG interfaces should be defined in a consistent way. Figure 1 represents the proposed FGs and an example of their interactions within the factory and tool environments.

8.5.1 PCSs may consist of a variety of capabilities or functions at both the factory and equipment level as shown in Figure 1. Moreover, this may include multiple instances of the same function type from different suppliers. In the example presented in Figure 1, several R2R controllers are running at the factory level with differences that are only visible as internal capabilities; these factory-level controllers could be providing R2R control at a lot-to-lot level of granularity, while the equipment level R2R controller could be providing W2W control, though any R2R control capability—including W2W control—can be provided inside or outside of the equipment as shown in Figure 1. This interface standard will facilitate easier collaboration between the tool level functions and factory level systems independent of the supplier that developed the internal function’s capabilities.



SEMI



Phone: 408.943.6900

DRAFT

Document Number:

Figure 1PCS Functions

9 PCS FG Capabilities and Interface Data Structures

9.1 FG Partitioning

9.1.1 PCS are partitioned into FGs using the criteria defined in § 8. This Standard defines the interface data structures, services and behavior associated with these FGs. In this section the capabilities of the PCS FGs are defined in more detail. First of all, the basic capabilities common to all FGs are presented. Then the additional basic capabilities unique to each FG are presented. A high level description of the specifications of data structures, services and behavior is provided in this section.

9.1.2 It is important to note that the specific implementations of these various FGs may differ greatly in the level of capability delivered, performance, quality of service, and internal architecture. Moreover, in a given factory, there may be multiple instances of the same FG running concurrently, from one or more suppliers. Some FGs may be completely independent of other PCS FGs (in other words, they can operate in relative isolation, depending only on information from systems external to PCS); others may depend heavily on other FGs, collaborating closely to provide a higher level of capability than they could on their own.

9.1.3 The goal of the PCS Interface Standards is to enable all of these implementation scenarios (and more) without dictating internal product architectures.

9.2 PCS AE

9.2.1 As defined in § 8, all FGs can be thought of as specializations of a PCS AE and therefore inherit the structure and behavior of a PCS AE. This section defines the common capabilities of a PCS AE.

9.2.2 General Capability Description

9.2.2.1 All PCS AEs shall have inputs and outputs as shown in Figure 2. This means that the PCS AEs shall support the consumption of the specified inputs and production of the specified outputs as necessary to achieve the required capabilities of that analysis engine as specified in this Standard. These inputs and outputs are specified as aggregate data structures. The structures are aggregated into ‘collection types’ according to the category of data. A definition of these collection types is provided in Table 4. The PCS AE shall have the general behavior of utilizing specified inputs, performing tasks based to some degree on these inputs, and generating outputs. Any additional structure and behavior of various PCS AEs are specified in the reminder of this section.This is a Draft Document of the SEMI International Standards program. No material on this page is to be construed as an official or adopted Standard or Safety Guideline. Permission is granted to reproduce and/or distribute this document, in whole or in part, only within the scope of SEMI International Standards committee (document development) activity. All other reproduction and/or distribution without the prior written consent of SEMI is prohibited.


SEMI



Phone: 408.943.6900

DRAFT

Document Number:

9.2.2.2 Note that, in addition to limitations of specification defined in § 4, the following are beyond the scope of definition of the PCS AE:

The level of synchronization of inputs with performance of tasks and/or generation of outputs, and

The specification of any internal states of the PCS AE.

9.2.2.3 All PCS AEs belonging to this FG shall have the capabilities listed in Table 5.

Figure 2PCS AE Common Input/Output Structure

9.2.2.4 Note that based on the simple data model shown in Figure 2, Inputs are available as an Output from an AE. Data provided as input to an AE should be accessible as output from the AE for historical purposes.

9.2.2.5 A part of the specification of this standard is the designation of the access level to attributes and structures within the overall common I/O structure. This is defined in section 9.2.3 with the terminology defined in section 7.2.6 . If access is specified as RW then it is RW if it is part of an AE Common Input Structure and RO if it is part of an AE Common Output Structure. If it is specified as RO then it is RO regardless of whether it is an Input or Output structure. If it is specified as NA then access level specification is beyond the scope of this standard. Note that if access is specified as NA then it is usually RO if it is part of an AE Common Output Structure.

Table 3[Table 5] PCS AE Inputs and Outputs Collection Type Definitions

Collection Type Definition Comments

Globals Information that applies globally across an entire job. A lot id, for example, could be specified once as a global so that it would not have to be specified with many other data sets.

AnalysisParameters Information that identifies numeric data used by the AE to perform various calculations.

Equation coefficients, feedforward data, etc.

CalculatedOutputs Data representing the results of analysis from an AE. A calculation derived from various inputs to the AE indicating wafer state, process state or model state information, recommended machine settings, etc.



SEMI



Phone: 408.943.6900

DRAFT

Document Number:

Collection Type Definition Comments

LogMessages Data describing the activity of an AE as it executes its tasks. Data describing the activities of the AE. Note that this does not include log information on the communication protocol with the AE. An example that is acceptable is “Algorithm #3 with model parameters ‘A’, ‘B’, and ‘C’.”

ModuleData Information representing the current or last known physical state of a process module that will be used by an AE to process material.

Machine, or module E10 state, RF hours, number of wafers processed, etc.

ProcessData Information representing the process itself, such as the name and type of the process and the current or last known process state based on measurements from sensors of the processing environment.

Name of the process (CMP), in situ process measurements, trace data, and summary statistics etc.

SubstrateData Information about the substrate being associated with the AE. This could include data representing a single wafer, multiple wafers, or one or more lots, as well as attributes of the material.

Profile or topology data, and other characteristics measured physically or electrically.

Table 4[Table 6] PCS AE FG Capabilities

# Description Reqd Comments

3.1 Provide a PCS AE capabilityPCS AE shall be capable of performing one or more of R2R control, FD, FC, FP, SPC, or any future functionality defined in this Standard as a PCS FG.

Y

3.2 Provide the required PCS AE methodsThe PCS AE shall provide the required interface services as defined in this Standard.

Y These include PCSAnalyze and PCS UpdateModel.

3.3 Maintain models of selected PCS environmentThe PCS AE shall maintain explicit or implicit models of the selected process control environment. These models shall be utilized to provide the analysis or control capability of the Analysis Engine.

Y The specific form and behavior of these models is beyond the scope of this Standard.

3.4 Provide a mechanism to uniquely instruct the AE to perform an actionThe PCS AE shall support an input mechanism whereby the analysis engine can be instructed to take a specific unique action.

Y The mechanism could be a single key variable; e.g., model name or a complex set of context data utilized internally to perform CM, etc. The action could include application of a specific model and generation of a PCS result, update of a model, or communication of model parameters.

3.5 Interface with multiple external systemsThe PCS AE shall be capable of accepting inputs from, or generating outputs to multiple external systems.

Y The definition of these systems will be a function of the application environment; these could include process tool or metrology systems, or user interfaces.



SEMI



Phone: 408.943.6900

DRAFT

Document Number:


3.6 Edit configuration of modelsThe PCS AE shall provide the capability to create/add, edit configuration, and delete models.

Y This capability will be supported through the Analysis Engine interface.

3.7 Interface with other AEsThe PCS AE shall be capable of either accepting outputs from other AEes as inputs, or producing outputs that are utilized by other AEs.

N May be a requirement of AEs belonging to a specific FG.

3.8 Advanced model managementThe PCS AE may provide advanced model management capabilities including but not limited to: secure access to models, and automatic updating of models based on process control environment changes.

N

9.2.3 Common Interface Data Structures

9.2.3.1 Common Data Model Overview — The common interface data structures from which all PCS FGs may inherit are shown in Figure 3. This figure shows the basic types of information (‘classes’ in object terminology) that can be supported by the interface. This model applies to the structure of inputs as well as outputs of a PCS AE as shown in Figure 2. This model applies to a complete message associated with a PCS job. That is it applies to the complete set of information communicated to or from a PCS AE for a PCS job. Note that a complete message into or out of a PCS AE may be broken into multiple application-to-application communications as defined in ¶ 9.2.3.5 .



SEMI



Phone: 408.943.6900

DRAFT

Document Number:

Figure 3AE Data Structure Model for a Complete Message Associated with a PCS Job

[9.2.3.2 ] Class Definitions — Class definitions consist of a brief description of each class, a table defining anydescription of its attributes belonging to that classand structures, and further text as necessary to fully define the class.

[9.2.3.2.1 ] AnalysisEngineDataSetAnalysisEngineDataSetType — A composite data structure that represents the data associated with a single input or output message of an AE.

[Table 7] Attributes of AnalysisEngineDataSetAnalysisEngineDataSetType

Attribute Name Description Access Reqd Form

PCSJobID A unique identifier of a PCS job. NARO C ObjID – Reference SEMI E39.

PCSAETargets An attributeA structure that indicates a list of AE types targeted by the AnalysisEngineDataSet.

NARW Y An ordered list of structured data of type PCSAETargetPCSAETargetType; see below.



SEMI



Phone: 408.943.6900

DRAFT

Document Number:


DataCollectionsStatus

An attributeA structure formatted as an extensible data structure that relates propertiesconveys the data being passed into or out of the success or failure of a PCS AE, identified in PCSAETargets, to execute a PCS job.

NARW CY An unordered list of structured data of type StatusElementDataCollectionType; see below.

[9.2.3.2.1.1 ] PCSJobID — The specification that PCSJobID is a requiredconditional attribute of AnalysisEngineDataSetAnalysisEngineDataSetType along with the specification that it is a unique identifier of a PCS job means that a unique PCSJobID shall be associated with each PCS job. The management of the uniqueness of the PCSJobID can be performed by an AE or by an application that wishes to utilize the capabilities of an AE. The application communicating with the AE is assumed to generate and manage PCSJobIDs for all PCS jobs, however the AE is required to provide this functionality in the event that the application does not wish to provide it. The existence of the PCSJobID attribute is conditional upon the following:

If the application communicating with the AE is managing a PCSJobID for a PCS job, then that PCSJobID shall be provided as the value of the PCSJobID attribute for all interface data structures of type AnalysisEngineDataSetAnalysisEngineDataSetType associated with that PCS job.

If the AE is providing the functionality of generating a PCSJobID for a PCS job, then the PCSJobID shall be provided in the first communication from the AE (to any consuming application) for this job and all subsequent communications associated with this job.

The PCSJobID is not required for transactions that do not involve the AE executing a PCS job such as status checks, or pre-processing queries.

[9.2.3.2.1.2 ] PCSAETargets — This attributestructure indicates a list of AE types targeted by the AnalysisEngineDataSetAnalysisEngineDataSetType instance; it is structured as an ordered list of type PCSAETargetPCSAETargetType (see below). At most one PCSAETargets value shall be associated with Each PCSJobID. Thus any two messages received by a PCS AE with the same PCSJobID will have at most one value for PCSAETargets, which could be provided in either or both messages. Each AE that receives this parameter in an input AnalysisEngineDataSetAnalysisEngineDataSetType instance will echo the parameter and its value for all output AnalysisEngineDataSetAnalysisEngineDataSetType messages with that PCSJobID.

[9.2.3.2.1.3 ] PCSAETarget — This attribute classDataCollections— This structure represents the data collections that are being passed into and out of the PCS AE Targets. Each DataCollection is a set of data and associated context for that data that conforms to the PCS AE common input/output structure as defined in ¶ 9.2.2.1

9.2.3.1.1 PCSAETargetType — A composite data structure that represents an AE targeted by the current PCS job. The PCSAETarget attribute is used to differentiate PCS AE targets when a single message travels between multiple AEs (often referred to as a ‘daisy chain’). In this case the AEType and AEInstance attributes of the PCSAETargetPCSAETargetType instance (see below) can be utilized to identify a particular consumer for the AnalysisEngineDataSetAnalysisEngineDataSetType data. Note that in many cases, such as point-to-point communications between an AE client and a single AE, the PCSAETarget attribute may not be necessary.

[9.2.3.2.1.3.1.1 ] This attribute has the following form:



SEMI



Phone: 408.943.6900

DRAFT

Document Number:

Figure 4 AE Data Structure Model Highlighting PCSAETarget Data Structure



SEMI



Phone: 408.943.6900

DRAFT

Document Number:

[Table 8] PCSAETarget Attribute Definition[Table 9] Attributes of PCSAETargetType


AEType An enumeration that represents the AE type to which the instruction is targeted.

NA NY EnumerationString that is an enumeration of AETypeSelector, with possible values being: fault detection (FDD), fault classification (FCC), fault prediction (FPP), run-to-run control (R2R), statistical process control (SPC), process control system (PCS).

AEAlgorithm A string indicating what algorithm name is being invoked NA Y String

AEInstance A number indicating the specific instance of an AE within a type that is targeted.

NA NY Integer.

AEOrder An integer indicating the order of execution for this PCSAETarget in the collection of PCSAETargets

NA Y Integer

Instructions An A structure that is ordered list of Instructions, where each instruction is of type text.

NA Y Ordered list of elements of type text.PCSAEInstructionType (see below).

StatusExtension This is the status of the PSCAETarget. . The This attribute allows the supplier to include additional information regarding the targeted AE instance.Status attribute exists at two levels. First as an attribute PCSAEInstructionType (see below), indicating the status of the individual instruction, and second as an attribute of PCSAETargetType (here) where it is a summary status of all of the PCSAEInstructionType status attributes.

NA NY Any.An ordered list of structured data of StatusElementType; (see below).

9.2.3.1.1.1 [9.2.3.2.1.4 ] The specification of how the AEs will consume the information is beyond the scope of this Standard.

9.2.3.1.1.2 [9.2.3.2.1.5 ] The AEType enumeration of ‘PCS’ is used to indicate a generic PCS type, or is an unspecified type.

9.2.3.1.1.3 [9.2.3.2.1.6 ] An AEAlgorithm value indicates the name of the algorithm that is being invoked from a group of algorithm types that are supported by the PCSAE. For example, a R2R PCSAE may have many different kinds of R2R algorithms to select from such as “EWMA”, or “Predictor Corrector”. The naming of the algorithms is beyond the scope of this document and is implementation specific.

9.2.3.1.1.4 An AEInstance value is not specified indicates that the instance of AEType is unspecified.

[9.2.3.2.1.6.1.1 ] When multiple PCSAETarget instance values are specified, the target PCS application to which these values refer should execute the PCS job associated with the PCSJobID in sequence. The mechanism for ensuring this behavior is beyond the scope of this Standard.



SEMI



Phone: 408.943.6900

DRAFT

Document Number:

[9.2.3.2.1.7 ] AEOrder specifies the order in which to execute the PCSAETargetType instances. This removes any question as to reordering, or

how PCSAETargets that have been executed are dispositioned.

9.2.3.1.1.5 Instructions — A structure that is an ordered list of elements, each of which is an instruction and is of type text.PCSAEInstructionType (see below). Note that no two elements in the ordered list can have the same value. An instruction is an attribute that relates a specific task that is being requested to be carried out by a targeted AEInstance.

[9.2.3.2.1.8 ] Status — This conditional attribute classstructure relates properties of the success or failure of a PCS AE, identified in PCSAETargets, to execute a PCS job. The attribute hasThe structure form is described below.

9.2.3.1.2 PCSAEInstructionType — A composite data structure that represents an Instruction associated with the following form:current PCS job.

Figure 5AE Data Structure Model Highlighting Instruction Data Structure



SEMI



Phone: 408.943.6900

DRAFT

Document Number:

Table 5 Attributes of PCSAEInstructionType


Instruction An enumeration that represents the instructions associated with the current PCS job.

NA N String that is an enumeration of the available PCS services. This includes, but is not limited to:PCSAnalyzePCSStartJobPCSAddMoreDataPCSEndJobPCSJobCompletedPCSAbortJobPCSJobAbortedPCSUpdateModelPCSEventPCSProduceLogDataPCSProduceExcpetionDataPCSExceptionProvucedPCSPingPCSCapabilitiesDiscoveryPCSEnableFDDFault

Order An integer indicating the order of execution for the Instructions NA Y Integer

Status This is the status of the execution of the instruction. The Status attribute exists at two levels. First as an attribute of PCSAEInstructionType (here), indicating the status of the individual instruction, and second as an attribute of PCSAETargetType where it is a summary status of all of the PCSAEInstructionType status attributes.

NA Y An ordered list of structured data of StatusElementType; see below.

Extension This structure allows the supplier to include additional information regarding the instruction. Details of this information are beyond the scope of this standard.

NA N An ordered list of structured data of DataItemType; see below.

9.2.3.1.3 StatusElementType — A composite data structure that represents the status of the stats of a PCS Job as it relates to a specific PCSAETarget.



SEMI



Phone: 408.943.6900

DRAFT

Document Number:

Figure 6AE Data Structure Model Highlighting StatusElement Data Structure

9.2.3.1.4 [9.2.3.2.2 ]

[Table 10] StatusElement Attribute Definition[Table 11] Attributes of StatusElementType


Source Represents the document from where the attribute code value is defined. For example ‘Source’ could identify a SEMI Standards Document. For status codes defined by SEMI Standards, the content of Source is the urn representation of the Standard number. For status codes defined by a supplier, it is the urn representation of the supplier’s name. (e.g., for SEMI E132 errors, the content of ‘Source’ is: urn:semi-org:E132; for supplier company errors, for instance, where company name is ‘Acme,’ the content is: urn:Acme-com) additional information may be included by the supplier by adding such information after the ‘:’ colon symbol and separating the fields with a ‘.’ period symbol. Please refer to SEMI E121 for additional information.

NA N Text.

Code A value that directly maps to a particular specification status code list. The source of this list is beyond the specification of this document. A status code of zero indicates that no error has occurred, while any non-zero status indicates an error has occurred. Specific error codes defined for this Standard are provided in Table 814.

NA Y Integer.



SEMI



Phone: 408.943.6900

DRAFT

Document Number:


Description A human readable description of the corresponding code attribute being reported. It maps directly to the definition of the Code attribute.

NA N An unordered list of structured data; see below.String.

Extension This attributestructure allows the supplier to include additional information regarding the status code encountered. Additional information may be supplied in this attributestructure to provide more detail about any error (e.g., Common Component, Code 5001: Insufficient Arguments Provided:Argument ‘SessionID’ missing).

NA N Any.An ordered list of structured data of DataItemType; see below.

Table 6[Table 12] SEMI E133 Code Attribute Value Definitions

StatusElement Parameter

Source Code Description Extension

SEMI E133 0 No error has occurred <manufacturer specific>

SEMI E133 ≠ 0 An error has occurred <manufacturer specific>

SEMI E133 −1 Message syntax error (e.g., XML validation error, see SEMI E133.1)

<manufacturer specific>

SEMI E133 −2 Unknown or unexpected PCSJobID <manufacturer specific>

SEMI E133 −3 Unknown or unexpected service <manufacturer specific>

SEMI E133 −4 Unknown or unexpected PCSAETarget <manufacturer specific>

SEMI E133 −5 Service not supported <manufacturer specific>

SEMI E133 −6 Service unavailable at this time <manufacturer specific>

SEMI E133 −7 Unknown or unexpected data item <manufacturer specific>

SEMI E133 −8 to −31 <Not specified: reserved for future generic AE use>


SEMI E133 −32 to −99 <Reserved for specific AE type use; reserved unless otherwise indicated in AE FG specification>


#1 <−99 Manufacturer specified <manufacturer specific>#1 >0 Manufacturer specified <manufacturer specific>

#1 Manufacturer Specific.

[9.2.3.2.2.1 ] The existence of the StatusElementStatus attribute is conditional on the properties of the message containing a data structure of type AnalysisEngineDataSet. The StatusElement attribute shall exist if and only if the following conditions apply:AnalysisEngineDataSetType. The Status object exists at two levels. First as an attribute of PCSAEInstructionType, indicating the status of the individual instruction, and as an attribute of PCSAETargetType where it is a summary status of all of the PCSAEInstructionType status attributes.

The message is an output from an AE.

The message is a response to a request for service(s) from that AE (e.g., a reply message).

[9.2.3.2.3 ] DataCollectionDataCollectionType — A set of data and associated context for that data that conforms to the PCS AE common input/output structure as defined in ¶ 9.2.2.1 .



SEMI



Phone: 408.943.6900

DRAFT

Document Number:

Figure 7AE Data Structure Model Highlighting DataCollectionType Data Structure



SEMI



Phone: 408.943.6900

DRAFT

Document Number:

Table 7 Attributes of DataCollectionDataCollectionType


BinCategory An enumerated identifier of the type of data collection among the possible types defined in the collection type enumeration, listed in Table 43.

NA Y String that is an enumeration of the type of data collection among the possible collection types listed in Table 5. They are:GlobalsAnalysisParametersCollectionType – As defined.CalculatedOutputsLogMessagesModuleDataProcessDataSubstrateData

Context A structure that is a collection of DataItems providing context for the data contained in the Data attribute

NA C DataItemType

Data A structure that is a collection of items of DataItemType containing the data being passed in the AnalysisEngineDataSetType

NA C DataItemType

[9.2.3.2.3.1 ] CollectionType — An enumeration of At least one of Context or Data structures must exist in a DataCollectionType.

9.2.3.1.4.1 DataItemType — A collection of BinCategory as defined in Table 4.

[9.2.3.2.4 ] DataItem — An individual componentcomponents of a data collection that, each of which has meaning in the PCS environment. Each data item hasAll members in the collection have a role of either ‘context’ or ‘data’ as determined by the client of the PCS AE.

[9.2.3.2.5 ]

Figure 8DataItemType Data Structure

Table 8 Attributes of DataItemDataItemType


Name Human-readable name for DataItem. NA Y StringValueString – See rules for naming below.



SEMI



Phone: 408.943.6900

DRAFT

Document Number:


Value An assigned or calculated quantity. NA Y AbstractValue – As defined in SEMI E134.Any

[9.2.3.2.5.1 ] Name — This attribute is used to provide a level of understanding of the meaning and purpose of the DataItemDataItemType. Names shall consist of alphanumeric characters, spaces, hyphens and underscores. Names shall start with an alpha character, and shall not contain leading or trailing spaces.

[9.2.3.2.5.2 ] Value — This attribute type is “Any” as defined in Section 7.3 . For example, see type AbstractValue (as defined in SEMI E134)). This is an abstract base class that is used to represent standard types including: Integer, Real, Boolean, String, Binary, Structure, Array, and Enumerations. In this way, parameter values collected via SEMI E134 may be passed directly into the PCS compliant AE via the value attribute of a DataItem. Refer to SEMI E134 for further definition of the AbstractValue type. AbstractValue base class allows for arbitrarily complex data items to be passed into the AE.

[9.2.3.2.5.3 ] A DataItemDataItemType that belongs to a DataCollectionDataCollectionType whose CollectionTypeBinCategoryType is ‘Globals’ may not serve a role of data (i.e., it can only serve the role of context).

9.2.3.1.4.2 [9.2.3.2.5.4 ] It is not required that the PCS AE utilize a data item in the same role (Data or Context) as is specified by the PCS AE client, however the PCS AE is required to maintain the role representation in I/O data structures produced or consumed across a PCS AE interface.

[9.2.3.3 ] Ordering of Elements Within an AnalysisEngineDataSetAnalysisEngineDataSetType Instance — In addition to compliance with a data structure model, this Standard also defines rules governing ordering of classes and attributes within each AnalysisEngineDataSetAnalysisEngineDataSetType instance, corresponding to the data content of an AE I/O message. Figure 6 provides a general illustration of this ordering. The following are rules governing that ordering.

[9.2.3.3.1 ] The first attribute of any AnalysisEngineDataSetAnalysisEngineDataSetType instance shall be the PCSJobID, if the PCSJobID value has been determined as defined in ¶ Error: Reference source not found.

[9.2.3.3.2 ] The first attribute of any DataCollectionDataCollectionType shall be BinCategory.

[9.2.3.3.3 ] The first member of DataCollection shall be of BinCategory ‘Globals’ if the AnalysisEngineDataSetAnalysisEngineDataSetType contains a DataCollectionDataCollectionType of that kind. At most one member of DataCollection shall be of BinCategory ‘Globals’ in any AnalysisEngineDataSet.

[9.2.3.3.4 ] In each DataCollection all DataItems whose role is ‘Context’ shall occur before the first DataItem whose role is ‘Data’ occurs.

[9.2.3.4 ] Additional Requirements of an AnalysisEngineDataSetAnalysisEngineDataSetType Instance

[9.2.3.4.1 ] If multiple AnalysisEngineDataSet instances are ‘related,’ as defined in ¶ 9.2.3.2.1 and both contain the same DataCollection with the same value of BinCategory, and further contain the same DataItem (with the same ‘Name’) within that DataCollection, the last DataItem shall be assumed to be correct. The interpretation of ordering of information as communicated by the underlying protocol is beyond the scope of this Document.

[9.2.3.4.2 ] Within an AnalysisEngineDataSetAnalysisEngineDataSetType instance or a group of instances that are ‘related,’ as defined in ¶ 9.2.2.1 , a DataItemDataItemType may exist within multiple DataCollectionTypesDataCollections that has a role of context. If this condition exists, the following rules shall apply.This is a Draft Document of the SEMI International Standards program. No material on this page is to be construed as an official or adopted Standard or Safety Guideline. Permission is granted to reproduce and/or distribute this document, in whole or in part, only within the scope of SEMI International Standards committee (document development) activity. All other reproduction and/or distribution without the prior written consent of SEMI is prohibited.


SEMI



Phone: 408.943.6900

DRAFT

Document Number:

[9.2.3.4.2.1 ] Any Context DataItemsDataItemType instances defined in a DataCollectionDataCollectionType with BinCategory = ‘Globals’ should be

used as a Context DataItemsDataItemType Instance for all other BinCategorysBinCategories in any related message except as defined in ¶ 9.2.3.4.2.2 9.2.3.4.2.2 below.

[9.2.3.4.2.2 ] If a DataCollectionDataCollectionType instance with a BinCategory other than ‘Globals’ defines a Context DataItemDataItemType instance that is also defined in the Global BinCategory of the current message or a related message, the local BinCategory DataItemDataItemType value should be used as context (i.e., the local DataItemType Context DataItemvalue overrides the Global value inside this DataCollectionDataCollectionType).

[9.2.3.5 ] Using Multiple Application-to-Application to Communications to Communicate a PCS Message — A PCS message may be broken into a number of application-to-application communications or partitions, however it is not required that a PCS AE support this partitioning capability. Each of these communication partitions must conform to the data model of FigureFigures 3 - 6, with the following modifications:

9.2.3.1.5 [9.2.3.5.1 ] PCSAETarget minimum cardinality is zero.



SEMI



Phone: 408.943.6900

DRAFT

Document Number:

PCSJobID == “[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}”

PCSAETargets

APCSAETarget: PCSAETarget

AEType == “R2R”

AEInstance == 1 Instructions

Instruction == “PCSAnalyze”

Extension == “execute serially”

Status

AStatusElement: StatusElement

Source == “urn:semi-org:E132”

Code == 0

ADataCollection: DataCollection

BinCategory == “Globals”

Role == “Context”

ADataItem: DataItem

AName: (type == text)

AValue: (type == any)

ADataItem



BinCategory == “ModuleData”


ADataItem: DataItem



…

Role == “Data”

ADataItem: DataItem



SEMI



Phone: 408.943.6900

DRAFT

Document Number:



…

BinCategory == “ProcessData”


ADataItem: DataItem



…

Role == “Data”

ADataItem: DataItem



…

…

[Figure 3]Illustration of Ordering of Information in an AnalysisEngineDataSet Instance

(Partial example; ‘…’ is used to indicate possible continuation in the listed format; PCSJobID in this example is aligned with specifications in SEMI E120.1)

[9.2.4 ] Common Interface Services

[9.2.4.1 ] Except as specified in the ‘EXCEPTIONS’ paragraph below, PCS AEs shall provide services by accepting and producing messages that are compliant with the common interface data structure as defined in § 9.2.3 . PCS AEs shall support both Request and Notification services as specified herein. For Request services, both the Request and Response messages associated with the service shall comply with the common interface data structure specified in § 9.2.3 , which includes a specification of required and optional elements. The success or failure of performing this service is conveyed in the Response message utilizing the ‘Code’ attribute (see ¶ 9.2.3.2.2.8 ). The ‘Code’ attribute is required in all response messages associated with request services. For Notification services, the message associated with the notification, whether produced or consumed by an AE, shall comply with the common interface data structure. Each service parameter, when provided in a service message, shall be provided as a DataItem in a data bin of the appropriate BinCategory (see FigureFigures 3, 6 and associated text), unless otherwise specified.

EXCEPTIONS: The following services are not required to comply with aspects of the common interface data structure as specifically noted.

PCSPing service: A Ping service response is not required to contain a PCSJobID parameter.

9.2.3.2 [9.2.4.2 ] All PCS AEs shall support the following common interface services:This is a Draft Document of the SEMI International Standards program. No material on this page is to be construed as an official or adopted Standard or Safety Guideline. Permission is granted to reproduce and/or distribute this document, in whole or in part, only within the scope of SEMI International Standards committee (document development) activity. All other reproduction and/or distribution without the prior written consent of SEMI is prohibited.


SEMI



Phone: 408.943.6900

DRAFT

Document Number:

9.2.3.2.1 [9.2.4.2.1 ] A set of services shall exist to support access to data from the engine.

9.2.3.2.2 [9.2.4.2.2 ] A set of services shall exist to support logging and exception handling.

9.2.3.2.3 [9.2.4.2.3 ] Specific services of an AE are invoked utilizing the Instructions element of the PCSAETarget attribute, as defined in § 9.2.3 . Specifically the service name is the value of an Instruction list element. For Request (Synchronous) services, the service name is the value of an Instruction list element for both the Request message and the corresponding Response message. For Notification services the service name is the value of an Instruction list element for the notification message. Utilizing this mechanism a set of services shall exist as defined in Table 11.

Table 9[Table 13] General AE Object Service Resource Definition#1


PCSAnalyze Y R Used to instruct an AE to compute and process a logical data sample. The results of the analysis are provided in the Response message. This service can be used for both synchronous and asynchronous PCS jobs.#2

PCSStartJob N R Used to instruct an AE to begin an asynchronous PCS job.#2

PCSAddMoreData N N Used to provide more raw data to an AE executing an asynchronous PCS job.#2 The AE consumes this notification message.

PCSEndJob N R Used to instruct an AE to complete an asynchronous PCS job.#2

PCSJobCompleted N N Used by the AE to indicate that an asynchronous PCS job has been completed.#2 The AE produces this notification message.

PCSAbortJob N N Used to abort (i.e., terminate) an asynchronous PCS job.#2 The AE consumes this notification message.

PCSJobAborted N N Used by the AE to indicate that an asynchronous PCS job has been aborted.#2 The AE produces this notification message.

PCSUpdateModel Y R Used to instruct the AE to update the analysis model with new information. This service can be used for both synchronous and asynchronous PCS jobs.#2

PCSEvent N N Used to provide an indication of detection of an event. An event could include the receipt of specific data. The specification of what constitutes the event is beyond the scope of this Standard.

PCSProduceLogData N R Used to instruct the AE to produce log messages. Information passed with a log data request could relate the date range and context associated with the request, while information returned could include the requested log data.

PCSProduceExceptionData N R Used to instruct the AE to provide information on the occurrence of exceptions raised by the AE. The exception information would be returned by the AE to the requestor, and could include a date range, similar to log data.

PCSExceptionProduced N N Used by the AE to indicate that an exception has occurred. The exception information provided with the notification could include a date range, similar to log data.

PCSPing Y R Used to ascertain the existence and communication health of the AE.

PCSCapabilitiesDiscovery N R Use to query a PCS AE as to its support of capabilities, including those defined in this Standard, and whether or not each capability is currently enabled or disabled. The value of the Capabilities DataItem (as defined in ¶ 9.2.4.2.4 ) in the service response indicates which capabilities are supported, and, among these, which are enabled and which are disabled.



SEMI



Phone: 408.943.6900

DRAFT

Document Number:


PCSEnable N R Used to put the PCS AE in a state where it is providing a subset of the capabilities it is specified as being capable of providing. The value of the Capabilities DataItem (as defined in ¶ 9.2.4.2.4 ) indicates which capabilities are requested to be enabled or disabled. The value of the Capabilities DataItem in the corresponding response indicates which capabilities were actually enabled.

#1 Except as specified in ‘EXCEPTIONS’ following ¶ 9.2.4.1, PCS AEs shall provide services by accepting and producing messages that are compliant with the common interface data structure as defined in § 9.2.3 .

#2 See § 9.2.5 .

9.2.3.2.4 [9.2.4.2.4 ] Service Parameters — Parameters for these services are described in Table 12.

[Table 14] PCS Service Parameter DefinitionDescription

BinCategory DataItem Name Description Role#1 Form

Globals DataSource Indicates the source or sources of data associated with this PCS job. For example, it could indicate an EDA tool and data collection plan.

D The form of the DataSource parameter is beyond the scope of this Standard. For example it could be a text string that identifies an EDA data source or context data to point to a particular interface on a particular tool.

Analysis-Parameters

Capabilities A complex data item containing:(1) a data element of Boolean form; a value of TRUE in a request service is an indication that ALL supported capabilities are to be enabled; a value of TRUE in a response service message is an indication that all capabilities are currently enabled; a value of FALSE in a request service is an indication that ALL supported capabilities are to be disabled; a value of FALSE in a response service message is an indication that not all capabilities are currently enabled.(2) A list of elements each of which provides information on each AE FG Capability, as listed in Tables 13 and 14, that is supported. Specifically each element in the list provides the following information;(2a) The number of the capability, as defined in this Standard, that is supported (e.g., R2R.A.1)(2b) The different ways in which the capability is supported.(2c) In a request message, an indication as to whether the capability is to be enabled or disabled; in a response message, an indication as to whether the capability is currently enabled or disabled.

D See description; additional specification of form is beyond the scope of this Standard.It is only required that this parameter be used to indicate which capabilities are supported.However, as desired indication of lack of support (e.g., via a value of FALSE) can be provided for 2b to indicate that a capability is not supported.

#1 Where, in the Role Column, D indicates ‘Data’ and C indicates ‘Context.’This is a Draft Document of the SEMI International Standards program. No material on this page is to be construed as an official or adopted Standard or Safety Guideline. Permission is granted to reproduce and/or distribute this document, in whole or in part, only within the scope of SEMI International Standards committee (document development) activity. All other reproduction and/or distribution without the prior written consent of SEMI is prohibited.


SEMI



Phone: 408.943.6900

DRAFT

Document Number:

9.2.3.2.4.1 [9.2.4.2.4.1 ] PCSStartJob — Table 13 describes the parameters specified for this service.

Table 10[Table 15] PCSStartJob Service Parameter Definition


DataSource C#1 - See § 9.2.4.2.4. See § 9.2.4.2.4.

#1 Parameter provided in the Request message if the service requestor wishes to indicate the data source or sources to be utilized in this (asynchronous) PCS job.

9.2.3.2.5 [9.2.4.2.5 ] PCSCapabilitiesDiscovery — Table 14 describes the parameters specified for this service.

Table 11[Table 16] PCSSCapabilitiesDiscovery Service Parameter Definition


Capabilities N R See § 9.2.4.2.4. See § 9.2.4.2.4.

9.2.3.2.6 [9.2.4.2.6 ] PCSEnable — Table 15 describes the parameters specified for this service.

Table 12[Table 17] PCSEnable Service Parameter Definition


Capabilities R R See § 9.2.4.2.4. See § 9.2.4.2.4.

9.2.4 [9.2.5 ] Common Behavior

9.2.4.1 [9.2.5.1 ] All PCS AEs shall be able to accept inputs and provide outputs through a combination of services which include those defined in Table 11, General AE Object Service Resource Definition.

9.2.4.2 [9.2.5.2 ] PCSJob Management Behavior

9.2.4.2.1 [9.2.5.2.1 ] A PCS AE provides PCS capabilities by executing PCS jobs. This section defines the behavior of the AE associated with the management of a PCS job in that AE. A PCS AE may manage multiple PCS jobs simultaneously. The maximum number of concurrent jobs that shall be maintained by an AE is beyond the scope of this Standard, however this section defines the behavior of each job that PCS AE is managing.

9.2.4.2.2 [9.2.5.2.2 ] The following PCS job behavioral classes are specified.

Synchronous PCS job: The AE responds to PCS job request message for a new job with a single response message produced that contains the response to the request that is the job output. After the response is issued by the AE, the job ends.

Asynchronous PCS job: The AE responds to PCS job requests message for a new job by opening a session with the requestor. During that session, for messages associated with that particular PCS job, the AE may respond synchronously to request messages (by producing appropriate response messages), consume notification messages without providing a response, and/or asynchronously produce notification messages. The asynchronous PCS job ends at an AE if any of the following conditions are met:



SEMI



Phone: 408.943.6900

DRAFT

Document Number:

A request to end the job is received by the AE via a PCSEndJob service, the AE determines that it can and should end the job, and the

AE sends a positive response to the request;

The AE determines that the job is complete and it should end the job, and provides a notification via the PCSJobCompleted service that the job has ended;

The AE receives a notification to abort the job via the PCSAbortJob service, and the AE can process the request;

The AE determines that it should abort the job and sends a notification to abort the job via the PCSJobAborted service.

9.2.4.2.3 [9.2.5.2.3 ] An AE may support one or both of these behavioral classes; additional specification as to this support may be provided in the individual AE type specification. The behavioral class to which the AE complies in executing a PCS job depends on the specific type of service request received (see § 9.2.4) and the capabilities of the AE.

9.2.4.2.4 [9.2.5.2.4 ] Additional specification of AE behavior can be found in the behavioral specifications for that specific analysis engine type. An AE may provide or specify additional behavior as long as it does not conflict with the behavior defined for that class in this Standard.

9.2.5 [9.2.6 ] AE General Capability Description

9.2.5.1 [9.2.6.1 ] An AE module should accept the following inputs and outputs using the common interface structure described in Figure 2. Not all inputs and outputs are required depending on the functionality needed by the AE.

9.2.6 [9.2.7 ] Inputs — The following data types and data values are used in AE input messages.

9.2.6.1 [9.2.7.1 ] No data types or data values are specified for the general AE.

9.2.7 [9.2.8 ] Outputs — The following data types and data values are used in AE output messages.

9.2.7.1 [9.2.8.1 ] No data types or data values are specified for the general AE.

9.3 R2R Control FG

9.3.1 This section defines the common capabilities and interface data structures of the R2R control FG. Note that this includes W2W control capabilities.

9.3.2 Table 16 below describes the specialization for the R2R control FG of each inherited general capability described in Table 5.

9.3.3 Table 17 describes the additional capabilities unique to the R2R control FG.

9.3.4 R2R General Capability Description

9.3.4.1 A R2R module should accept the following inputs and outputs using the common interface structure described in Figure 2. Not all inputs and outputs are required depending on the functionality needed by the R2R model. For example, R2R function may only need feedback data in the form of Substrate Data.

9.3.5 Inputs — The following data types and data values are used in R2R control input messages:

9.3.5.1 The R2R controller AE inherits the input data structure and data structure requirements from the PCS AE.

9.3.5.2 The following data types and data type values shall be supported by a R2R control AE when included in an input data structure, where supported means that the AE will be able to utilize the information provided by the data type and perform any indicated action associated with that data:



SEMI



Phone: 408.943.6900

DRAFT

Document Number:

9.3.5.2.1 PCSAETarget Class

9.3.5.2.1.1 Attribute AEType with a value of ‘R2R.’

9.3.5.2.1.2 A list element of attribute Instructions with a value of ‘PCSAnalyze.’

9.3.5.2.1.3 A list element of attribute Instructions with a value of ‘PCSUpdateModel.’

9.3.6 Outputs — The following data types and data type values are used in R2R control output messages:

9.3.6.1 The R2R controller AE inherits the output data structure and data structure requirements from the PCS AE.

9.3.6.2 The following data types and data type values shall be supported by a R2R control AE when included in an output data structure, where supported means that the AE will be able to provide these data types and values when behavioral conditions warrant, as indicated below.

9.3.6.2.1 DataCollection Class — The following DataItem Names or Name/Value pairs shall be supported for DataItems in the specified BinCategory.

9.3.6.2.2 ControlAdvice — This attribute contains the control advice, structured as an unordered list of name-value pairs. The method in which the control advice is utilized is beyond the scope of this Document.

Table 13[Table 18] R2R Control FG Inherited Capabilities


R2R.I.1 Provide a R2R control capability as defined in § 5The R2R control AE shall be able to accept process quality data, and utilize this data to generate advice on how to improve future processing; specifically, a R2R implementation shall provide a capability for modifying recipe parameters or the selection of control parameters between runs to improve processing performance. A ‘run’ can be a batch, lot, or an individual wafer (specified in the context).

Y Based on definition of R2R control.

R2R.I.2 Provide the required PCS AE MethodsThe R2R control AE shall provide the required interface services as defined in this Standard.

Y These include PCSAnalyze and PCSUpdateModel.

R2R.I.3 Maintain R2R models of selected PCS environmentThe R2R control AE shall maintain explicit or implicit R2R models of the selected process control environment. These models shall be utilized to provide the R2R control capability. These models shall dynamically represent the state of the system based on information received by the AE relating to the selected process control environment as well as configuration information.

Y The specific form and behavior of these models is beyond the scope of this Standard; however they generally model aspects of the process(es) or tool(s) being controlled.

R2R.I.4 Provide a mechanism to uniquely instruct the AE to perform an actionThe R2R control AE shall support an input mechanism whereby the AE can be instructed to take a specific unique action.

Y The mechanism could be a single key variable; e.g., model name or a complex set of context data utilized internally to perform CM, etc. The action could include application of a specific model and generation of a PCS result, update of a model, or communication of model parameters.



SEMI



Phone: 408.943.6900

DRAFT

Document Number:


R2R.I.5 Interface with multiple external systemsThe R2R control AE shall be capable of accepting inputs from, or generating outputs to multiple external systems.


R2R.I.6 Basic model managementThe R2R control AE shall provide the capability to create/add, edit configuration, and delete R2R control models.

Y This capability will be supported through the AE interface.

R2R.I.7 Interface with other AEsThe R2R control AE shall be capable of either accepting outputs from other AEs as inputs, or producing outputs that are utilized by other AEs.

N The R2R control AE is not required to interface with other AEs, however examples of use of interface capabilities would be utilizing SPC and/or FD information to determine model parameter updates or controller actions.

R2R.I.8 Advanced model managementThe R2R control AE shall provide advanced model management capabilities including but not limited to: secure access to models, and automatic updating of models based on process control environment changes.

N

Table 14[Table 19] Additional R2R Control FG Capabilities


R2R.A.1 Accept and utilize feedback dataThe R2R control AE shall be able to accept historical information about the target process control environment, and advice adjustments for improving processing based on this data; typical feedback data is post process metrology information from previous process events on the target process.In the context of R2R control, feedback data is defined as data that is utilized to improve capability for future process runs.

Y The controller must utilize feedback information to maintain dynamic models.

R2R.A.2 Automatically configure internally for control of a target processThe R2R control AE shall be able to request and/or accept information about the specific process control environment as necessary, and automatically configure to provide control of the process. For example, the R2R control AE may request and utilize experimental data to determine optimal baseline control models for the target process.

C#1 Item R2R.A.2 and/or R2R.A.3, required.

R2R.A.3 Support manual configuration for control of a target processThe R2R Control Analysis Engine shall be able to request and/or accept configuration information so that the Analysis Engine may be configured by an external system to provide control of the process.

C#1 Item R2R.A.2 and/or R2R.A.3, required.



SEMI



Phone: 408.943.6900

DRAFT

Document Number:


R2R.A.4 Accept and utilize feedforward dataThe R2R control AE shall be able to accept information about current material to be processed and adjust recommendations for improving processing based on this data.In the context of R2R control, feedforward data is defined as data that is utilized to improve capability for the current process run.

N

R2R.A.5 Support enabling and disabling of providing the control capability as defined in R2R.I.1

N Enabling/disabling is supported by the PCSEnable and PCSDisable services respectively.

R2R.A.6 Accept and utilize overrides of recipe advicesThe R2R control AE shall be able accept and utilized overrides of recipe advices, originally generated as a result of providing capability R2R.I.1. The method in which the override information is utilized is beyond the scope of this document.

N Both the originally generated and override results are provided utilizing the ControlAdvice Data Type.

R2R.A.7 Provide W2W controlThe R2R control AE shall be able to generate R2R control advices, as defined in R2R.I.1, for each wafer before processing of each wafer begins. Support of this capability can be provided in one or more ways that are itemized as follows:– Provides capability R2R.I.1 for a number of wafers in a group before the processing of the first wafer in that group begins.– Provides capability R2R.I.1 for each wafer after the processing of the previous wafer.

N This W2W control capability is often restricted to on-tool R2R AEs. Support of this capability does not dictate how the control advice is provided (e.g., as a differential from a baseline, or as an absolute value) or how the settings are utilized.

R2R.A.8 Supports coordinated control with another R2R AE (‘coordinating controller’)The R2R control AE shall support the utilization of R2R advice (as defined in R2R.I.1) provided by another R2R AE. The manner in which the AE utilizes R2R control advices is beyond the scope of this document.

N This capability is usually associated with W2W control and is often restricted to on-tool R2R AEs. Support of this capability could mean for example that the on-tool W2W controller could utilize off-tool setting recommendations as a starting point or baseline for W2W control. Note that the ‘advice information’ as specified here could be considered as a portion of the ‘configuration information’ specified in R2R.A.3.

R2R.A.9 Provide publishing of R2R control advices generatedThe R2R control AE shall be able to provide information of control advices generated for a particular PCS job; this information is provided via the LogMessages collection type as defined in Table 3. Support of this capability can be provided in one or more ways utilizing the R2RInformationLog service that are itemized as follows:– Provide the capability upon request– Provide the capability as a notification

N This capability would be provided utilizing the R2RInformationLog service in request or notification form.



SEMI



Phone: 408.943.6900

DRAFT

Document Number:


R2R.A.10 Provide publishing of R2R control advices usedThe R2R control AE shall be able to provide information of control advices used for a particular PCS job; this information is provided via the LogMessages collection type as defined in Table 3. Support of this capability can be provided in one or more ways utilizing the R2RInformationLog service that are itemized as follows:– Provide the capability upon request– Provide the capability as a notification


R2R.A.11 Provide publishing of process control targetsThe R2R control AE shall be able to provide information of control targets used by the AE for a particular PCS job; this information is provided via the LogMessages collection type as defined in Table 3. Support of this capability can be provided in one or more ways utilizing the R2RInformationLog service that are itemized as follows:– Provide the capability upon request– Provide the capability as a notification


R2R.A.12 Provide publishing of control model parametersThe R2R control AE shall be able to provide information about the control model used by the AE for a particular PCS job; this information is provided via the LogMessages collection type as defined in Table 3. Support of this capability can be provided in one or more ways utilizing the R2RInformationLog service that are itemized as follows:– Provide the capability upon request– Provide the capability as a notificationDetails as to the type of control model information that should be provided as part of this capability are beyond the scope of this Standard.

N This capability would be provided utilizing the R2RInformationLog service in request or notification form.Control model parameter information could include controller gain, controller noise filtering, control limits, parameter weights, and algorithm selection.

#1 C indicates ‘conditional’ with the conditions specified in the Comment column.



SEMI



Phone: 408.943.6900

DRAFT

Document Number:

Table 15[Table 20] Data Types Required to be Supported by an Input Message for an AE

BinCategory DataItem Name Value Description Role#1 Reqd Form

CalculatedOutputs

ControlAdvice NA#2 A set of name-value pairs that constitute a control advice. Context associated with the AnalysisEngineDataSet Input may identify the system to which the R2R control recipe advice parameters are expected to be applied.

D Y Any.

LogMessages R2RInformation NA#2 A set of name-value pairs that provide, at minimum, one or more of the following:– R2R Control Advice generated– R2R Control Advice used– R2R Control targets– R2R Control gain used– R2R Control model usedAn indication of ‘data not available’ can be conveyed through a specific value in each name-value pair.

D N R2R Control Advice values provided in form of ControlAdvice; Form of other components of DataItem not specifiedNote that an indication of “Data Not Available” could be a possible value for a particular parameter.

#1 Where, in the Role column, D indicates ‘data’ and C indicated ‘context.’

#2 NA indicates ‘not applicable,’ because specification is on DataItem as opposed to a specific value of DataItem.

9.3.7 R2R Interface Services

9.3.7.1 The R2R control AE inherits Common Interface Services as specified in § 9.2.4.

9.3.7.2 The R2R AE shall additionally support the following services.

Table 16[Table 21] Additional R2R AE Object Service Resource Definition#1

Service Reqd Type2 Description

R2RInformationLog N R or N Used to determine information provided by or utilized by the R2R AE in the past in providing capability R2R.I.1, as specified in Table 13. The log information is communicated through the R2RInformation DataItem as defined in Table 15. This service can be provided as a Request/Response service, or as a Notification service. A PCSJobID parameter is used to indicate the PCS job associated with the information being provided.

#1 Except as specified in ‘EXCEPTIONS’ following ¶ 9.2.4.1, PCS AEs shall provide services by accepting and producing messages that are compliant with the common interface data structure as defined in § 9.2.3.

9.3.7.3 The PCSCapabilitiesDiscovery and PCSEnable services are required.

9.3.8 R2R Interface Behavior

9.3.8.1 The R2R AE inherits Common Interface Behavior as specified in § 9.2.5.



SEMI



Phone: 408.943.6900

DRAFT

Document Number:

9.3.8.2 The R2R AE shall additionally support the following behavior.

9.3.8.2.1 The R2R AE shall support the Synchronous PCS job behavioral class and optionally support the Asynchronous PCS job behavioral class, as specified in ¶ 9.2.5.2.2.

9.3.8.2.2 If a R2R AE receives an input message of type AnalysisEngineDataSet for a process control job, and, in a PCSAETarget attribute, one of the list of instructions in the Instructions attribute has a value of ‘PCSAnalyze,’ then the R2R control shall provide capability R2R.I.1 (see Table 16). Specifically the AE shall provide an output message of type AnalysisEngineDataSet that contains the data item name ‘ControlAdvice’ in a DataCollection where BinCategory = ‘CalculatedOutputs.’

9.3.8.2.3 If a R2R AE receives an input message of type AnalysisEngineDataSet for a process control job, and, in a PCSAETarget attribute of that message, one of the list of instructions in the Instructions attribute has a value of ‘PCSUpdateModel,’ then the R2R control AE shall utilize information provided as part of the associated PCS job to update control models as necessary. The determination of need to update models and the method in which these models are updated is beyond the scope of this Standard.

9.4 FD FG

9.4.1 This section defines the common capabilities of the FD FG.

9.4.2 Table 20 describes the specialization for FD of each inherited general capability described in Table 5.

Table 17[Table 22] FD FG Inherited Capabilities


FDD.I.1 Provide a FD capability as described in § 5The FD system shall analyze provided input data with the purpose of detecting anomalies/faults.

Y Detailed inputs and outputs to be defined in a future version of the Standard. However it is expected that the FD engine will provide output sufficient to analyze why the engine determined there was a fault.

FDD.I.2 Provide the required PCS AE methodsThe FD AE shall provide the required interface services as defined in this Standard.


FDD.I.3 Maintain models of selected PCS environment(s)The FD AE shall maintain explicit or implicit models of the selected process control environment. These models shall be used to detect anomalies in the supplied data.


FDD.I.4 Provide a mechanism to uniquely instruct the AE to perform an actionThe FD AE shall support an input mechanism whereby the analysis engine can be instructed to take a specific unique action.

Y The mechanism could be a single key variable, e.g., model name or a complex set of context data utilized internally to perform CM, etc. The action could include application of a specific model and generation of a FD result.

FDD.I.5 Interface with multiple external systemsFD AE shall be capable of accepting inputs from, or generating outputs to multiple external systems.


FDD.I.6 Basic model managementThe FD AE shall provide the capability to create/add models, edit configuration of models, and delete models.

Y This capability will be supported through the FD Analysis Engine interface.



SEMI



Phone: 408.943.6900

DRAFT

Document Number:


FDD.I.7.1 Interface with FC AEThe FD AE shall be capable of providing output that can be used by a PCS-compliant FC AE.

Y Output to FC is required. Other interfaces are optional.

FDD.I.7.2 Interface with other AEsFD AE shall be capable of either accepting outputs from other AEs as inputs, or producing outputs that are utilized by other AEs.

N For example, using R2R outputs to distinguish between controller changes and faults.

FDD.I.8 Advanced model managementThe FD AE shall provide advanced model management capabilities including but not limited to: secure access to models, and automatic updating of models based on process control environment changes.

N

9.4.3 Table 21 describes the additional capabilities unique to the FD FG.

Table 18[Table 23] Additional FD FG Capabilities


FDD.A.1 Provide an interface for automatic notification of detected faultsThe FD AE shall provide an interface to automatically notify an external system when a fault is detected. The interface must provide enough information about the detected fault for the external system to make decisions about notification.

Y The external system may for example: page or e-mail an engineer, or take the tool in question off-line. Information provided in the interface should include: context, severity, and any fault details (TBD in a future version of the Standard).

FDD.A.2 Ability to test against reference/simulation dataThe system should provide the ability to test and evaluate FD models against historic, reference or simulated data without affecting the production environment.

N This capability could be provided off-line; i.e., as a capability that is available in a mode when other required FD capabilities are not necessarily available.

FDD.A.3 Ability to interdict process/toolThe system should be capable of initiating the interdiction of a process, either directly or indirectly, in a timely manner, in order to prevent or prohibit the creation of out-of-spec material. This is needed when the general event notification and/or interdiction system(s) cannot respond fast enough to protect people, plant, or product.

N NOTE: This would be in addition to the capability defined in FD.I.1 above.

9.4.4 FD General Capability Description

[9.4.4.1 ] An FD module should accept the following inputs and outputs using the common interface structure described in Figure 52. Not all inputs and outputs are required depending on the functionality needed by the FD AE.

9.4.5 Inputs — The following data types and data values are used in FD input messages:

9.4.5.1 The FD AE inherits the input data structure and data structure requirements from the PCS AE.



SEMI



Phone: 408.943.6900

DRAFT

Document Number:

9.4.5.2 The following data types and data type values shall be supported by a FD AE when included in an input data structure, where supported means that the

AE will be able to utilize the information provided by the data type and perform any indicated action associated with that data:


9.4.5.2.1.1 Attribute AEType with a value of ‘FDD.’

9.4.6 Outputs — The following data types and data type values are used in FD output messages:

9.4.6.1 The FD analysis engine inherits the output data structure and data structure requirements from the PCS Analysis Engine.

9.4.7 FD Interface Services

9.4.7.1 The FD AE inherits Common Interface Services as specified in § 9.2.4.

9.4.7.2 The inherited PCSEvent service shall be required.

9.4.7.3 The FD AE shall additionally support the following services.

Table 19[Table 24] Additional FD AE Object Service Resource Definition#1

Service Reqd Type#2 Description

FDDFault Y N Used to provide a FD capability through notification of an anomaly or fault event as specified in § 5 and Table 20.


#2 See § 9.2.5.

9.4.8 FD Interface Behavior

9.4.8.1 The FD AE inherits Common Interface Behavior as specified in § 9.2.5.

9.4.8.2 The FD AE shall additionally support the following behavior.

9.4.8.2.1 The FD AE shall support both the Synchronous PCSJob and Asynchronous PCSJob behavioral classes as specified in ¶ 9.2.5.4.2.

9.5 FC FG

9.5.1 This section defines the common capabilities of the FC FG.

9.5.2 Table 23 describes the specialization for FC of each inherited general capability described in Table 5 above.

9.5.3 Table 24 describes the additional capabilities unique to the FC FG.

Table 20[Table 25] FC FG Inherited Capabilities


FCC.I.1 Provide a FC capability as described in § 5The FC system shall analyze provided input detected or predicted fault data with the purpose of determining the root cause of the fault.

Y Detailed inputs and outputs to be defined in a future version of the Standard.



SEMI



Phone: 408.943.6900

DRAFT

Document Number:


FCC.I.2 Provide the required PCS AE methodsThe FC AE shall provide the required interface services as defined in this Standard.


FCC.I.3 Maintain models of selected PCS environment(s)FC AE shall maintain explicit or implicit models of the selected process control environment. These models shall be used to classify the input fault data into probable root cause categories.


FCC.I.4 Provide a mechanism to uniquely instruct the AE to perform an actionThe FC AE shall support an input mechanism whereby the analysis engine can be instructed to take a specific unique action.

Y The mechanism could be a single key variable; e.g., model name or a complex set of context data utilized internally to perform CM, etc. The action could include application of a specific model and generation of a FC result.

FCC.I.5 Interface with multiple external systemsFC AE shall be capable of accepting inputs from, or generating outputs to multiple external systems.


FCC.I.6 Basic model managementThe FC AE shall provide the capability to create/add models, edit configuration of models, and delete models.

Y This capability will be supported through the FD AE interface.

FCC.I.7.1 Interface with FD AEThe FC AE shall be capable of accepting the appropriate output of a PCS-compliant FD AE.

Y FC AE may require additional inputs to perform classification operation (i.e., FD output may not be sufficient as sole input).

FCC.I.7.2 Interface with FP AEThe FC AE shall be capable of accepting the appropriate output of any PCS-compliant FP AE.

N FC AE may require additional inputs to perform classification operation (i.e., FP output may not be sufficient as sole input).

FCC.I.7.3 Interface with other AEsThe FC AE shall be capable of either accepting outputs from other AEs as inputs, or producing outputs that are utilized by other AEs.

N

FCC.I.8 Advanced model managementThe FC AE shall provide advanced model management capabilities including but not limited to: secure access to models, and automatic updating of models based on process control environment changes.

N

Table 21[Table 26] Additional FC FG Capabilities


FCC.A.1 Ability to perform automated classificationAutomated classification allows for classification to occur automatically after a fault is detected or predicted (in-line). This ability results in faults classified with some degree of confidence without user intervention.

R



SEMI



Phone: 408.943.6900

DRAFT

Document Number:


FCC.A.2 Ability to perform manual classificationManual classification allows classification to occur manually after a fault is detected or predicted (inline). This ability may result in a new classification being defined or a new association to an existing classification established.

O

FCC.A.3 Ability to perform remote reclassification of production and archived faultsRe-classification should be required offline. This allows for new association to be made that may not be the result of an online classification.

N

FCC.A.4 Ability to communicate references to agents that might make use of the information such as troubleshooting guides (TSGs), out of control action plan (OCAP) systems, and computerized maintenance management systems (CMMSs)Classification should allow users to link to outside agents such as TSG, OCAP systems and CMMSs. This means that, in addition to application-to-application communication, the classification information provided by the FC engine can be interpreted by the outside agent; e.g., a classification can be mapped to a maintenance activity in a CMMS or an action plan in an OCAP system.

N

FCC.A.5 Ability to indicate that a fault cannot be classified, and to tag unclassified faults for future classificationIn some cases, data analysis does not reveal a classification of a fault, or does not reveal a classification that is appropriate for reporting. Also, to avoid inline delays it is often necessary to defer classification until further studies are made. This may be the result of automated, manual, or re-classification tasks.

N

FCC.A.6 Produce list of classifications by a method such as confidence or probabilityMetric to identify the classification confidence must be the result of classification. Optionally all the classifications that have any nominal confidence should be listed.

N An example is a Pareto presentation, such as classification candidates along with their probability of being the source of the fault.

FCC.A.7 Ability to provide for FC of a non-equipment systemFC does not have to be limited to classification of equipment faults.

N Examples include FC of a R2R control AE or a software system.

FCC.A.8 Ability to accept data on the fault that was classified, and adapt to or learn from this informationThe classification system should accept feedback that provides the results of investigation of a particular FC that was communicated, and adapt or improve internal classification capabilities. The method for adapting or improving is beyond the scope of this Standard.

N As an example, if the FC AE reports a Pareto of possible FCs, the client of the FC system might report back the actual cause of the problem among the possibilities.



SEMI



Phone: 408.943.6900

DRAFT

Document Number:


FCC.A.9 Ability to support further investigation of a reported FCThe classification system should provide a capability for further inquiry into details associated with a reported FC.

N This capability is often referred to as ‘drill-down’ and could include reporting of raw and processed data associated with the classification, classification calculations, and data quality indicators. It could also include transactions to support step-wise decision-tree style analysis of classification information.

9.5.4 FC General Capability Description

[9.5.4.1 ] An FC module should accept the following inputs and outputs using the common interface structure described in Figure 52. Not all inputs and outputs are required depending on the functionality needed by the FC AE.

9.5.5 Inputs — The following data types and data values are used in FC input messages:

9.5.5.1 The FC AE inherits the input data structure and data structure requirements from the PCS AE.

9.5.5.2 The following data types and data type values shall be supported by a FC AE when included in an input data structure, where supported means that the AE will be able to utilize the information provided by the data type and perform any indicated action associated with that data:


9.5.5.2.1.1 Attribute AEType with a value of ‘FCC.’

9.5.5.2.1.2 A List element of attribute ‘Instructions’ with a value of ‘PCSAnalyze.’

9.5.5.2.1.3 (Optional) A List element of attribute ‘Instructions’ with a value of ‘PCSUpdateModel.’

9.5.6 Outputs — The following data types and data type values are used in FC output messages:

9.5.6.1 The FC AE inherits the output data structure and data structure requirements from the PCS AE.

9.5.6.2 The following data types and data type values shall be supported by a FC AE when included in an output data structure, where supported means that the AE will be able to provide these data types and values when behavioral conditions warrant, as indicated below.

9.5.6.3 SEMI E133 Code Attribute Value Definitions — The following additional Code attribute value definitions shall be supported (see Table 8 also).

Table 22[Table 27] FC FG Code Attribute Value Definitions

Source Code Description Extension

SEMI E133 −32 Unable to provide classification information. <manufacturer specific>

SEMI E133 −33 Unable to provide classification information at this time. <manufacturer specific>

9.5.6.3.1 DataCollection Class — The following DataItem Names or Name/Value pairs shall be supported for DataItems in the specified BinCategory.



SEMI



Phone: 408.943.6900

DRAFT

Document Number:

Table 23[Table 28] Data Types Required to be Supported by an Input Message for an Analysis Engine

BinCategory DataItem Name Value Description Role#1 Reqd Form

Calculated-Outputs

FaultClassifi-cationAdvice

NA#2 The FC information. The structure of this attribute is beyond the scope of this Standard. For example, the information could be an ordered list of a structure that contains the classification and the classification probability, as a Pareto report. Context associated with the AnalysisEngineDataSet Input may identify the system to which the FC information applies.

D Y Any.

#1 Where, in the Role column, D indicates ‘data’ and C indicated ‘context.’

#2 NA indicates ‘not applicable,’ because specification is on DataItem as opposed to a specific value of DataItem.

9.5.6.3.2 FaultClassificationAdvice — This attribute contains the FC information. The structure of this attribute as well as the method in which the FC advice is utilized is beyond the scope of this Document.

9.5.7 FC Interface Services

9.5.7.1 The FC analysis engine inherits Common Interface Services as specified in § 9.2.4.

9.5.7.2 The inherited PCSEvent service shall be required.

9.5.7.3 The FC analysis engine shall additionally support the following services.

Table 24[Table 29] Additional FC AE Object Service Resource Definition#1

Service Reqd Type#2 Description

FCCClassification N N Used to provide a FC capability through notification of a classification event as defined in § 5 and Table 21. This notification service is only utilized if the FCC AE is operating in an Asynchronous behavioral mode, as defined in § 9.2.5.


#2 See § 9.2.5.

9.5.7.3.1 The following parameters are specified for this service:

Table 25[Table 30] FCCClassification Service Parameter Definition

Parameter#1 Requirement Form Description

FaultClassificationAdvice Y See Table 22. See Table 22.

#1 Parameter provided in the Notification message if the AE can provide the appropriate classification information. See § 9.5.8 for further information.

9.5.8 FC Interface Behavior

9.5.8.1 The FC AE inherits Common Interface Behavior as specified in § 9.2.5.

9.5.8.2 The FC AE shall additionally support the following behavior.



SEMI



Phone: 408.943.6900

DRAFT

Document Number:

9.5.8.3 The FC AE shall support both the Synchronous PCSJob and optionally support Asynchronous PCSJob behavioral classes as specified in ¶ 9.2.5.4.2.

9.5.8.3.1 If the FC AE receives an input message of type AnalysisEngineDataSet for a process control job, and, in the PCSAETarget attribute of that message, one of the list of instructions in the Instructions attribute has a value of ‘PCSAnalyze,’ then the FC AE shall provide capability FCC.I.1 (see Table 23). Specifically the AE shall provide an output message of type AnalysisEngineDataSet that contains the data item name ‘FaultClassificationaAdvice’ in a DataCollection where BinCategory == ‘Calculated Outputs.’

9.5.8.3.2 If the FC AE receives an input message of type AnalysisEngineDataSet for a PCS job, and, in the PCSAETarget attribute of that message, one of the list of instructions in the Instructions attribute has a value of ‘PCSUpdateModel,’ and, further, if the FCC.I.8 or FCC.A.8 (see Tables 23 and 24) capabilities are supported, then the FC AE shall utilize the information provided as part of the associated PCS job to update classification models as necessary. The determination of the need to update models and the method in which these models are updated is beyond the scope of this Standard.

9.5.8.3.3 If the FC AE supports asynchronous PCS job behavior it will utilize the FCCClassification notification service to report classification information associated with an open asynchronous PCS Job. Specific classification information is reported utilizing the FaultClassificationAdvice service parameter. Indication of the lack of capability to provide classification information is communicated by utilizing the appropriate Status Element Code attribute value (see Table 8). The utilization of the FaultClassificationAdvice service parameter in this case is beyond the scope of the Standard, though the parameter may be used to communicate details regarding the lack of ability to provide classification information.

9.6 FP FG

9.6.1 This section defines the common capabilities of the FP FG.

9.6.2 Table 29 describes the specialization for FP of each inherited general capability described in Table 5 above.

9.6.3 Table 30 describes the additional capabilities unique to the FP FG.

Table 26[Table 31] FP FG Inherited Capabilities


FPP.I.1 Provide a FP capability as described in § 5The FP system shall analyze provided input data with the purpose of determining if a fault will occur in a future run.

Y Detailed inputs and outputs to be defined in a future version of the Standard. However, it is expected that the FP output will provide enough information to determine why and when the engine determined a fault will occur.

FPP.I.2 Provide the required PCS AE methodsThe FP AE shall provide the required interface services as defined in this Standard.


FPP.I.3 Maintain models of selected PCS environment(s)FP AE shall maintain explicit or implicit models of the selected process control environment. These models shall be used to predict faults based on the supplied input data.




SEMI



Phone: 408.943.6900

DRAFT

Document Number:


FPP.I.4 Provide a mechanism to uniquely instruct the AE to perform an actionThe FP AE shall support an input mechanism whereby the AE can be instructed to take a specific unique action.

Y The mechanism could be a single key variable; e.g., model name or a complex set of context data utilized internally to perform CM, etc. The action could include application of a specific model and generation of a FP result.

FPP.I.5 Interface with multiple external systemsFP AE shall be capable of accepting inputs from, or generating outputs to multiple external systems.


FPP.I.6 Basic model managementThe FP AE shall provide the capability to create/add models, edit configuration of models, and delete models.


FPP.I.7.1 Interface with FC AEThe FP AE shall be capable of providing output that can be used by any PCS-compliant FC AE.

Y

FPP.I.7.2 Interface with other AEsThe FP AE shall be capable of either accepting outputs from other AEs as inputs, or producing outputs that are utilized by other AEs.

N

FPP.I.8 Advanced model managementThe FP AE shall provide advanced model management capabilities including but not limited to: secure access to models, and automatic updating of models based on process control environment changes.

N

Table 27[Table 32] Additional FP FG Capabilities


FPP.A.1 Provide an interface for automatic notification of predicted faultsThe system must provide an interface to automatically notify an external system when a fault is predicted. The interface must provide enough information about the predicted fault for the external system to make decisions about notification.

Y The external system may for example: page or email an engineer, or take the tool in question off-line. Information provided in the interface should include: context, severity, and any fault details (TBD in a future version of the Standard).

FPP.A.2 Ability to perform advanced statistical/prediction algorithms on data to enable FP after a specific number of runs, tool time or productsWhat is the probability that a specific fault will happen, when, what are action plans that can be taken, which tools, what is the predictive classification of a specific fault.

N

FPP.A.3 Ability to build a prediction model from historical dataBased on the historical data, a learning-based model may be developed. A specific pattern of historical data may give information about a future fault possibility.

N



SEMI



Phone: 408.943.6900

DRAFT

Document Number:


FPP.A.4 Ability to predict preventive maintenance scheduling based on tool/substrate informationThis will reduce tool downtime.

N

9.7 SPC FG

9.7.1 This section defines the common capabilities of the SPC FG.

9.7.2 Table 31 below describes the specialization for SPC of each inherited general capability described in Table 5 above.

9.7.3 Table 32 describes the additional capabilities unique to the SPC FG.

9.7.4 SPC General Capability Description

9.7.4.1 An SPC engine should accept the following inputs and outputs using the common interface structure described in Figure 2. Not all inputs and outputs are required depending on the functionality needed by the SPC AE.

9.7.5 Inputs — The following data types and data type values are used in SPC input messages:

9.7.5.1 The SPC engine inherits the input data structure and data structure requirements from the PCS AE.

9.7.5.2 The following data types and data type values shall be supported by an SPC AE when included in an input data structure, where supported means that the AE will be able to utilize the information provided by the data type and perform any indicated action associated with that data:


9.7.5.2.1.1 Attribute AEType with a value of ‘SPC.’

9.7.5.2.1.2 A list element of attribute Instructions with the possible values of the instructions supporting the synchronous methods inherited from the PCS AE.

9.7.5.2.2 DataCollection Class: data types and data type values for SPC input parameters are SPC AE vendor specific and beyond the scope of this Standard.

9.7.6 Outputs — The following data types and data type values are used in SPC AE output messages:

9.7.6.1 The SPC AE inherits the output data structure and data structure requirements from the PCS AE.

9.7.7 SPC Interface Services

9.7.7.1 The SPC AE inherits Common Interface Services as specified in § 9.2.4.

9.7.8 SPC Interface Behavior

9.7.8.1 The SPC AE inherits Common Interface Behavior as specified in § 9.2.5.

9.7.8.2 The SPC AE shall additionally support the following behavior:

9.7.8.2.1 The SPC AE shall support the Synchronous PCSJob behavioral class and optionally support the Asynchronous behavioral class as specified in § 9.2.5.2.2.



SEMI



Phone: 408.943.6900

DRAFT

Document Number:

Table 28[Table 33] SPC FG Inherited Capabilities


SPC.I.1 Provide a SPC capability as described in § 5The SPC system shall analyze provided input data with the purpose of determining if statistically significant deviations from normal have occurred.

Y Based on the definition of SPC.

SPC.I.2 Provide the required PCS AE methodsThe SPC AE shall provide the required interface services as defined in this Standard.


SPC.I.3 Maintain models of selected PCS environment(s)The SPC AE shall maintain statistical distribution models. Such models can be selected automatically during gathering of input data and can be selected for the specific process to be monitored.

Y The SPC AE supports normal and various non-normal statistical deviation models. The specific form and behavior of these models is beyond the scope of this Standard.

SPC.I.4 Provide a mechanism to uniquely instruct the AE to perform an actionThe SPC AE shall support an input mechanism whereby the AE can be instructed to take a specific unique action.

Y The mechanism could be a single key variable; e.g., model name or a complex set of context data utilized internally to perform CM, etc. The action could include application of a specific model (SPC rule) and generation of a SPC result.

SPC.I.5 Interface with multiple external systemsSPC AE shall be capable of accepting inputs from, or generating outputs to multiple external systems.


SPC.I.6 Basic model managementThe SPC AE shall provide the capability to create/add models, edit configuration of models, and delete models.


SPC.I.7 Interface with other AEsThe SPC AE shall be capable of either accepting outputs from other AEs as inputs, or producing outputs that are utilized by other AEs.

N

SPC.I.8 Advanced model managementThe SPC AE may provide advanced model management capabilities including but not limited to: secure access to models, and automatic updating of models based on process control environment changes.

N



SEMI



Phone: 408.943.6900

DRAFT

Document Number:

Table 29[Table 34] Additional SPC FG Capabilities


SPC.A.1 Functionality to perform trend analysisThe SPC AE shall provide an automated analysis of data for the identification of undesired trends using industry standard run rules such as (for example) Western Electric.#1 One result of these calculations and comparisons should be a decision of whether or not the new data caused the ‘chart’ to go out of control. The mathematics available must include those items listed in item #SPC.A.4 below.

N More flexible rules may be required but are subject to the specific implementation.

SPC.A.2 Functionality to support standard control chartsThe SPC AE shall provide the ability to plot data as well as display traditional variables charts, and attributes charts. The system should also provide access to the data to enable a third party system to display control charts.

N Typical charts would include Shewart and CuSum Charts optionally with smoothing such as exponential weighted mean average charts (EWMA).#1

SPC.A.3 Functionality to perform statistical analysisThe SPC AE shall provide tools for statistical analysis.

Y This may include the ability to calculate statistical metrics, normal analysis, and non-normal analysis. This is subject to the specific implementation.

SPC.A.4 Functionality to calculate control limitsThe SPC AE shall provide abilities to calculate control limits for control charts from historical data using at minimum industry standard techniques for calculating upper and lower control limits for variables and attributes charts based on sub-group size, sample size, etc. Other techniques can be utilized as desired to augment the standard techniques. Elimination of outliers is an integral part for control limits calculation and the SPC AE shall have an algorithm to support that capability.

N

SPC.A.5 Provide an interface for automatic notification of processing anomaliesThe SPC AE shall provide an interface to automatically notify an external system when an assignable cause statistical anomaly is detected. The interface must provide enough information about the detected problem to the external system to make decisions about notification.

N The external system may for example page or e-mail an engineer, or take a tool off-line. Information provided in the interface should include: context, severity, and any fault details.The kind of interface and the way of setting up the notification target is beyond the scope of this Standard.The information provided should allow the consumer of that information to understand the context of the problem; thus the information should include as necessary information on tools, chambers, wafers, processes and products.



SEMI



Phone: 408.943.6900

DRAFT

Document Number:


SPC.A.6 Functionality to provide a reference to an Out-of-Control Action Plan (OCAP)The SPC AE shall store a reference to an action plan that is to be put into effect in the case of the trend analysis determining that an out of control condition exists.

N The OCAP maybemay be a part of the SPC AE or part of another system accessible from the SPC AE. In either case, for this requirement to be met, the SPC AE must have a capability to trigger a specific OCAP. The OCAP implementation specification is outside the scope of this Standard.

SPC.A.7 Ability to store user problem resolution commentsThe SPC AE shall provide a place for users to put in comments on how the problem was corrected. This may also be used by the statistical analysis system to store information related to the OOC point to speed up diagnosis and problem resolution.

N

#1 For an explanation of the Western Electric Company Rules (WECO) see, for example, the NIST/SEMATECH e-Handbook of Statistical Methods; http://www.itl.nist.gov/div898/handbook/, 7/18/2006.

10 Compliance to PCS Standard

10.1 This section defines requirements placed on PCSs for claiming compliance with this Standard and verifying compliance with this Standard. The Standard does NOT include specific verification test plans, but there should be enough information in the Standard to generate these.

10.2 Approach

10.2.1 This Standard specifies the interfaces for PCS FGs. Compliance with this Standard is verified through testing these interfaces to verify compliance of data structures and behavior to the extent specified in this Standard.

10.2.2 As noted in § 9, all PCS AE are characterized as having a set of capabilities, and a collection of inputs and outputs, with the outputs being a function of the inputs. The general approach to compliance testing then is to first document the capabilities, and then test the inputs and outputs by (1) generating inputs for the PCS AE to consume and (2) observing corresponding outputs of the engine. It is understood that there are a number of behavior models that an AE shall use to consume inputs and produce outputs, such as active polling by the engine or a request message from an outside source to the AE. The compliance testing method should utilize a mechanism that works with the behavioral model of the AE for subscription to (i.e., consumption of) inputs and publication of (i.e., production of) outputs.

10.2.3 Note also that all PCS AEs inherit a set of common requirements. Thus, the approach for testing any PCS AE should be to first verify compliance to the common requirements, and then verify compliance to the requirements specific to the particular FG.

10.3 Scope of Compliance Verification

10.3.1 Compliance Verification shall address the following:

Documentation of FG capabilities

10.3.2 Future version of this Standard will also address the following compliance verification:

Capability to accept all required inputs

Capability to accept properly formatted interface data structures



SEMI



Phone: 408.943.6900

http://www.itl.nist.gov/div898/handbook/,%207/18/2006

DRAFT

Document Number:

Capability to produce all required outputs; these outputs may be in response to the inputs as specified herein

Capability to produce properly formatted output data structures

10.3.3 Compliance verification will not address the following:

Engine response to improperly formatted inputs

Quality of Service (QoS) of data in output structures produced by engine

Quality of Performance (QoP) of engine in producing output structures (e.g., in response to receipt of input structures)

10.4 Statement of Compliance (SoC) — FG Capabilities Data Sheet

[10.4.1 ] All PCS AEs claiming compliance with this Standard are required to be delivered with a statement of compliance sheet on FG capabilities. This sheet specifies for the user which functional capabilities, specified as required or conditional in this Standard, are available with this engine. The format of the SoC sheet is given in Table 2733, which includes a description of the fields of this sheet:

Table 30[Table 35] PCS AE SoC FG Capabilities Data Sheet

Company Company Name

Product Product Name

Version Software Revision Number, etc.

Functional Group(s) Functional Group(s) to Which Compliance is Claimed

Functional Group Capabilities

- Functional Group #1

# Description Requirement Supported Comments

- Functional Group #2

# Description Requirement Supported Comments

10.4.1 [10.4.2 ] Company — Name of company supplying product.

10.4.2 [10.4.3 ] Product — Name of product being supplied.

10.4.3 [10.4.4 ] Version — Any additional descriptors that supplier applies to product (such as software revision number) that, along with Product Name, uniquely identifies product.

10.4.4 [10.4.5 ] Functional Group(s) — The FGs, as defined in this Standard, to which compliance is being claimed.

10.4.5 [10.4.6 ] Functional Group Capabilities — The FG capabilities as specified in this Standard for the FGs to which compliance is being claimed (as indicated in the ‘Functional Group(s)’ field). Note that all capabilities specified in this Standard for the FGs, to which compliance is being claimed, must be listed, and are organized by the fields below.



SEMI



Phone: 408.943.6900

DRAFT

Document Number:

10.4.6 [10.4.7 ] Functional Group #n — The name of the ‘n-th’ functional group to which compliance is being claimed (e.g., R2R, FD, FC, FP, or SPC).

10.4.7 [10.4.8 ] # — The index number (copied from the ‘#’ field for that capability).

10.4.8 [10.4.9 ] Description — The FG capability description copied verbatim from this Standard (copied from the ‘Description’ field for that capability), for the PCS AE FG listed.

10.4.9 [10.4.10 ] Requirement — The requirement of the capability as defined in this Standard (copied from the ‘Requirement’ field for that capability).

10.4.10 [10.4.11 ] Supported — This field contains the PCS AE provider’s claim of support of this capability. The claim could be ‘Yes’ (Y), ‘No’ (N), ‘Conditional’ (C), or ‘Optional’ (O). Note that if the capability is listed as a requirement then it must be supported.

10.4.11 [10.4.12 ] Comment — This field contains any additional information that the PCS AE provider may wish to provide. Note that if the ‘Supported’ field is listed as ‘Conditional’ or ‘Optional,’ the conditionality or optionality conditions must be delineated in this field.

10.5 PCS AE Compliance Verification Procedure

10.5.1 The following procedure should be applied to all PCS AE:

10.5.2 Compliance — Functional Group Capabilities Data Sheet Verification Test:

Is a properly formatted SoC data sheet supplied with product?

Pass Criteria:

A properly formatted SoC data sheet, as specified in ¶ 10.3 is provided with the product.

The Product + Version fields uniquely identify the product.

At least one FG is claimed (i.e., the engine declares to belong to at least one FG as specified in this Standard).

All FG capabilities for each FG claimed in the ‘Functional Group’ field are listed as defined in § 9, and the requirement field matches that provided for each capability in § 9.

For each capability listed as required, it must also be supported (i.e., if Requirement = ‘Y’, then Supported = ‘Y’).

For each capability listed as conditional, the conditions, defined in § 9, must be met.

For each capability listed as optional (i.e., not required), a declaration of whether the requirement is supported must be made (i.e., the ‘Supported’ field for this requirement must be filled in).

10.6 Condition of Compliance

10.6.1 A PCS AE can be considered to be compliant with this Standard if and only if it passes all of the compliance tests for the AE in ¶ 10.5.



SEMI



Phone: 408.943.6900

DRAFT

Document Number:

RELATED INFORMATION 1

PCS EVENT NOTIFICATION AND DATA COLLECTION USING INTERFACE A

NOTICE: This Related Information is not an official part of SEMI E133 and was derived from the work of the global Information & Control Technical Committee. This Related Information was approved for publication by full letter ballot procedures on November 21, 2006.

R1-1 Overview

R1-1.1 PCS Deployment

R1-1.1.1 It is expected in the future that PCS based applications may collect events and data from equipment that have implemented Interface A, also referenced as equipment data acquisition (EDA). In order to meet this requirement a mapping between PCS messages that specify PCS job flow and equipment data collection with Interface A will be needed. This Related Information section presents a Use Case which demonstrates an approach that will accomplish this requirement as well as sample PCS message formats.

R1-2 Implementation Approach Example

R1-2.1 FD AE/EDA Connectivity Example

R1-2.1.1 The block diagram presented below (Figure R1-1) illustrates one example of an implementation approach that provides connectivity between a FD AE and equipment with an EDA Port in support of event and data collection.

Client Application(outside world)

EquipmentEDA Port

FD AE

EDA Connector

EquipmentEDA Port

Protocol #2 Connector

Data SourcePort

Figure R1-1 Example Architecture Block Diagram

(other implementation architectures are allowed)This is a Draft Document of the SEMI International Standards program. No material on this page is to be construed as an official or adopted Standard or Safety Guideline. Permission is granted to reproduce and/or distribute this document, in whole or in part, only within the scope of SEMI International Standards committee (document development) activity. All other reproduction and/or distribution without the prior written consent of SEMI is prohibited.


SEMI



Phone: 408.943.6900

DRAFT

Document Number:

R1-2.2 Client Application

R1-2.2.1 The Client Application initiates FD AE action by requesting the start of a PCS job. The FD AE will provide events and data back to the Client Application based on the data source specified (global parameter sent with PCSStartJob request). The FD AE will continue to execute the job until a request is received to end the PCS job.

R1-2.3 FD AE

R1-2.3.1 The FD AE is responsible for providing PCS FD capabilities by executing PCS FD jobs. It receives requests from the Client Application and then sends out messages to collect data from specified equipment, or other fab applications as appropriate or necessary to execute the specified job.

R1-2.3.1.1 Messages received from the Client Application ideally are SEMI E133 compliant. If not then an application programming interface (API) converter will be necessary. The API converter will map client messages received to the appropriate SEMI E133 message format and map SEMI E133 FD AE response messages to the correct client format.

R1-2.3.1.2 When processing a PCS job the FD AE will send messages to the EDA Connector which is responsible for the actual connectivity with the appropriate EDA equipment. As requested event and data is received from the equipment the EDA Connector will return the information to the FD AE.

R1-2.4 EDA Connector

R1-2.4.1 The EDA Connector will provide the connectivity between the equipment and FD AE. The EDA Connector can support multiple connections to equipment with an EDA Port and will manage the SEMI E134 messages sent to the equipment for enabling data collection. It may be part of the FD AE or implemented as a separate module.

R1-2.4.1.1 The EDA Connector will use the data source specified in the start PCS job message to determine which data collection plans are to be activated and on which equipment. The data source may specify a pre-defined data collection plan or provide the information necessary to dynamically create, define and activate.

R1-2.4.1.2 Data will continue to be received and forwarded to the FD AE until a request is received to deactivate a data collection plan. This request will be send from the FD AE upon receipt from the Client Application a message to end the PCS job.

R1-2.5 Protocol Connector

R1-2.5.1 While not part of EDA, the Protocol Connector illustrated in Figure R1-2 was included to show that the FD AE is not limited to one type of connection for data.

R1-3 Message Flow

R1-3.1 High Level View of PCS/EDA Interaction Example

R1-3.1.1 Figure R1-2 below shows a high level message scenario for the implementation of FD AE with EDA enabled equipment. The message sequence is executed when the Client Application receives a trigger to start a PCS job for FD.

R1-3.1.1.1 The Client Application will send to the FD AE a start request which in turn will cause the FD AE to enable data collection on the appropriate equipment. The FD AE will return data to the client application by linking the EDA event to a PCS message. For this example the return of EDA data results in a PCS Event and (after data analysis by the FD AE) a FD Fault message being sent to the Client.



SEMI



Phone: 408.943.6900

DRAFT

Document Number:

R1-3.1.1.2 It needs to be noted that at this time the two messages in italics are not in the SEMI E133 Standard but are planned for in a subsequent SEMI E133

ballot.

Client Application

FD AE with EDA

PCSStartJobResponsePCSStartJobResponsePCSStartJobRequestPCSStartJobRequest

EDA Data

FDFaultFDFault

PCSEventPCSEvent

PCSEndJobResponsePCSEndJobResponsePCSEndJobRequestPCSEndJobRequest

FD JobTriggered

FD JobTriggered

Figure R1-1 High Level Message Flow

R1-3.2 PCS/EDA Message Scenario Example

R1-3.2.1 Figure R1-3 is a sample message scenario which shows the message flow between the Client Application, FD AE with EDA Connector, and Equipment.



SEMI



Phone: 408.943.6900

DRAFT

Document Number:

Client Application Equipment

EstablishSessionRequestEstablishSessionRequest

MetadataRequestMetadataRequestMetadataResponseMetadataResponse

PCSStartJobRequestPCSStartJobRequest

PCSStartJobResponsePCSStartJobResponse

DefinePlanRequestDefinePlanRequest

ActivateRequestActivateRequest

NewDataNotification (DataReport)NewDataNotification (DataReport)

FDFaultFDFault NewDataNotification (DataReport)NewDataNotification (DataReport)

PCSEventPCSEvent

PCSEndJobRequestPCSEndJobRequestDeactivateRequestDeactivateRequest

PCSEndJobResponsePCSEndJobResponse

DefinePlanResponseDefinePlanResponse

ActivateResponseActivateResponse

EstablishSessionResponseEstablishSessionResponse

DeactivateResponseDeactivateResponse

FD AE with EDA

Figure R1-1 PCS/EDA Message Scenario Example

R1-3.3 Session, Metadata Request/Response

R1-3.3.1 The first four messages in Figure R1-3 show the establishment of a session with the EDA Port on the equipment and the request for Metadata. Although these are shown prior to the PCSStartJob request they may occur after that request and is dependent on the application.

R1-3.4 PCSStartJob Request/Response

R1-3.4.1 The PCSStartJob request is the trigger used by the FD AE to begin collecting data and returning it to the Client Application. In this example this data source in the message will be used by the FD AE to define and activate a data collection plan (DCP). Once the FD AE completes initial processing it notifies the Client Application as to the status of the request by sending back PCSStartJob response.

R1-3.5 DCP Define, Activate Request/Response

R1-3.5.1 The messages DefinePlan request and Activate request define the DCP to the equipment and tell the EDA Port to activate the plan. At that point any data reported by the equipment associated with a DCP will be returned to the FD AE. There can be multiple DCPs defined and the actual plans activated are dependent on the data source specified in the PCSStartJob request. Note: Although these messages are shown after the PCSStartJob request is issued they could be executed prior to this if the DCP was pre-defined. This is application dependent.

R1-3.6 PCS Event/FDD Fault

R1-3.6.1 The example message flow above shows data from the equipment (NewData notification) being tied to PCSEvent and FDDFault, where the FDDFault message would generally result from FD AE analysis of the data and determination that a fault notification should occur. The decision of data mapping to PCS message will be



SEMI



Phone: 408.943.6900

DRAFT

Document Number:

determined in this case by the FD AE. It needs to be noted that at this time the two messages in italics are not in the SEMI E133 Standard but are planned for

in a subsequent SEMI E133 ballot.

R1-4 Message Examples

R1-4.1 PCSStartJob request Message

R1-4.1.1 The following XML listing shows one method of sending the PCSStartJob request with an embedded data collection plan. In that the Standard does not define a format for DataSource it allows the PCS DCP definition (in italics) to be mapped closely to the format specified by SEMI E134 simplifying the mapping from PCS to EDA message formats. It is recommended by the PCS Task Force that DataSource be put in the global bin. In this PCS DCP there are three requests, two event requests and one trace request, the number of requests is dependent on the application.

<AnalysisEngineDataSet xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="C:\SemiDocs\TaskForceStandards\APC\Pcs.xsd">

<PCSJobID>”pcsJob1”</PCSJobID>

<PCSAETarget>

<AEType>FDD</AEType>

<AEInstance>0</AEInstance>

<Instructions>

<Instruction>PCSJobStart request</Instruction>

</Instructions>

</PCSAETarget>

<Globals>

<Context>

<DataSource>

<PCSDataCollectionPlanType

name="FDC_DCP_ALL_OK"

description="Fault Detection DCP One – Standard Oper." >

<Event request

equipmentId="ImplanterModel"

sourceId="Implanter>IonImplanter>EndStation"

eventId="EndOfWafer" >

<Parameter request

equipmentId="ImplanterModel"This is a Draft Document of the SEMI International Standards program. No material on this page is to be construed as an official or adopted Standard or Safety Guideline. Permission is granted to reproduce and/or distribute this document, in whole or in part, only within the scope of SEMI International Standards committee (document development) activity. All other reproduction and/or distribution without the prior written consent of SEMI is prohibited.


SEMI



Phone: 408.943.6900

DRAFT

Document Number:

sourceId="Implanter>IonImplanter>EndStation>FaradayCup"

parameterName="BeamCurrent"/>

<Parameter request



parameterName="Bias"/>

</Event request>

<Event request


sourceId="Implanter"

eventId="FDC_Fault_On_EndOfWafer" >

<Parameter request



parameterName="FDC_Data"/>

<Parameter request



parameterName="FDC_Result"/>

</Event request>

<Trace request

id="2"

intervalInSeconds="3"

collectionCount="6"

groupSize="2" >

<Parameter request





SEMI



Phone: 408.943.6900

DRAFT

Document Number:

parameterName="FilamentCurrent" />

</Trace request>

</PCSDataCollectionPlanType>

</DataSource>

<Context>

</Globals>

</AnalysisEngineDataSet>

R1-4.2 PCSEvent Message

R1-4.2.1 The following XML listing shows how data received from the equipment’s EDA Port would be formatted and returned to the Client Application. In this example we show how a response to the Trace request may be represented. As the data is coming directly from the equipment it is the recommendation of the PCS Task Force that this information be put into the ModuleData Bin. In that the Standard does not specify a specific format for data returned the reporting of information closely maps to the EDA message representation ( in italics). Note this message is not in the SEMI E133 Standard but is planned for inclusion in a subsequent SEMI E133 ballot.



<PCSAETarget>



<Instructions>

<Instruction>PCSEvent</Instruction>

</Instructions>

</PCSAETarget>

<ModuleData>

<Context>

<DCR reportTime="2006-07-31T14:23:00.4375-05:00"

equipmentID="ImplanterModel"

planName="FDC_DCP_ALL_OK">

<TraceReport traceId="2" />

</DCR>This is a Draft Document of the SEMI International Standards program. No material on this page is to be construed as an official or adopted Standard or Safety Guideline. Permission is granted to reproduce and/or distribute this document, in whole or in part, only within the scope of SEMI International Standards committee (document development) activity. All other reproduction and/or distribution without the prior written consent of SEMI is prohibited.


SEMI



Phone: 408.943.6900

DRAFT

Document Number:

</Context>

<Data

reportTime="2006-07-31T14:23:00.4375-05:00">

<TR collectionTime="2006-07-31T14:22:57.4375-05:00">

<PV>

<F8>1.1</F8>

</PV>

</TR>

<TR collectionTime="2006-07-31T14:23:00.4375-05:00">

<PV>

<F8>1.1</F8>

</PV>

</TR>

</Data>

</ModuleData>


R1-4.3 FDDFault Message

R1-4.3.1 The following XML listing shows how data received from an EDA Port would be formatted and returned to the Client Application. In this example we show how a response to the Event request may be represented. For this example we have assumed that calculations have been done on the data received at the equipment level so this data is mapped to the Calculated Output Bin. In that the Standard does not specify a specific format for data returned the reporting of information closely maps to the EDA message representation (in italics). Note at this message is not in the SEMI E133 Standard but is planned for in a subsequent SEMI E133 ballot.



<PCSAETarget>



<Instructions>



SEMI



Phone: 408.943.6900

DRAFT

Document Number:

<Instruction>FDDFault</Instruction>

</Instructions>

</PCSAETarget>

<CalculatedOutputs>

<Context>

<DCR reportTime="2006-07-31T14:23:29.6875-05:00"

equipmentID="ImplanterModel"

planName="FDC_DCP_ALL_OK">

<EventReport sourceId="Implanter"

eventId="FDC_Fault_On_EndOfWafer" />

</DCR>

</Context>

<Data>

<eventTime="2006-07-31T14:23:29.6875-05:00">

<PV>

<F8>1.1000000238418579</F8>

</PV>

<PV>

<F8>2.2000000476837158</F8>

</PV>

</Data>

</CalculatedOutputs>




SEMI



Phone: 408.943.6900

DRAFT

Document Number:


PCS W2W CONTROL

NOTICE: This Related Information is not an official part of SEMI E133 and was derived from the work of the global Information & Control Technical Committee. This Related Information was approved for publication by full letter ballot procedures on September 4, 2009.

R2-1 Overview

R2-1.1 PCS W2W Control Deployment

R2-1.1.1 SEMI E133 provides documentation for R2R control communication. W2W control (as defined in SEMI E133) is an important type of R2R control. This Related Information section illustrates how the PCS standard communication capabilities could be leveraged to coordinate inside equipment and outside equipment PCS control capabilities to support W2W control.

R2-1.1.2 Coordination of inside equipment and outside equipment capabilities for R2R control is an important application that should be discussed. For example most equipment today supports GEM/SECS interface capabilities (SEMI E30) and/or the emerging XML interface standards (e.g., SEMI E134). Coordination of inside equipment and outside equipment capabilities via communication scenarios should be described that could be implemented utilizing these protocols. This Related Information section illustrates how the PCS standard communication capabilities would be utilized in these scenarios. Note that the specific way in which these capabilities are implemented utilizing a specific equipment communication protocol (e.g., GEM/SECS) is outside the scope of this Related Information specification at this time.

R2-2 Implementation Approach Example

R2-2.1 High Level View

R2-2.1.1 Figure R2-1 is a high level view of the control environment illustrating an equipment with an embedded W2W control capability and a configuration client. The configuration client could be a host computer.

Equipment withW2W Control

Configuration Client(Host)

Figure R2-1 High Level View of W2W Control Environment

R2-2.1.2 A typical W2W control scenario would involve the following steps:



SEMI



Phone: 408.943.6900

DRAFT

Document Number:

Discovery — Determine what capabilities the W2W controller has.

Enable — Turn on or off available select capabilities as needed; the available capabilities are determined in the Discovery step.

Control — Invoke the W2W controller AE to provide control.

Report — Retrieve from the W2W controller AE or have the AE publish information related to the control process.

R2-2.1.2.1 These steps would involve PCS communications between the equipment and the configuration client. These communications would be via PCS services.

R2-2.2 Communication Scenarios

R2-2.2.1 Introduction

R2-2.2.1.1 The following communication scenarios identify the PCS services used to support steps associated with providing W2W control.

R2-2.2.1.2 In the associated figures, parameters associated with a particular service that are required or otherwise pertinent to the description of the communication scenario are indicated inside the parenthesis following that service. The notation of ‘…’ inside a parenthesis following a service is used to indicate (additional) parameters, some of which may be necessary as specified in the SEMI E133 Standard.

R2-2.2.1.3 Discovery — Figure R2-2 illustrates the communication scenario to support the Discovery step. The PCSCapabilitiesDiscovery service is used and the Capabilities parameter is used in the response by the AE to indicate which capabilities (from the R2R control capabilities table) are supported, and which of these supported capabilities are currently enabled.

W2W Controller

EquipmentProcessing

Configuration Client

PCSCapabilitiesDiscoveryRequest(…)

PCSCapabilitiesDiscoveryResponse(Capabilities, …)

Equipment

Figure R2-1 Discovery Communication Scenario

R2-2.2.1.4 Enable — Figure R2-3 illustrates the communication scenario to support the Enable step. The PCSCapabilitiesEnable service is used. The Capabilities parameter is used in the request to indicate which capabilities are to be enabled or disabled. The Capabilities parameter in the response indicated which Capabilities are enabled or disabled (as a result of the execution of this service). Note, of course that only capabilities that are This is a Draft Document of the SEMI International Standards program. No material on this page is to be construed as an official or adopted Standard or Safety Guideline. Permission is granted to reproduce and/or distribute this document, in whole or in part, only within the scope of SEMI International Standards committee (document development) activity. All other reproduction and/or distribution without the prior written consent of SEMI is prohibited.


SEMI



Phone: 408.943.6900

DRAFT

Document Number:

supported (as determined through the Discovery service) should be requested to be enabled or disabled.

Equipment

W2W Controller

EquipmentProcessing


PCSEnableRequest(Capabilities, …)

PCSEnableResponse(Capabilities, …)

Figure R2-1 Enable Communication Scenario

R2-2.2.1.5 Control — Figure R2-4 illustrates the communication scenario to support the W2W Control step. The PCSAnalyze service is utilized by the entity requiring W2W control services (such as the equipment) to retrieve control advices from the W2W control AE; as with all R2R control PCS capabilities these control advices are communicated via the ControlAdvice parameter. The R2R control model is updated utilizing the PCSUpdateModel service. Note that the PCSUpdateModel service can be executed by the entity that is requiring the control services, or by an outside agent, such as a host. The determination of which agent is managing this service is implementation dependent. For example it could be dependent on which agent is collecting the pre- and post-metrology data associated with the process. Note that the PCSAnalyze and PCSUpdateModel services could be utilized multiple times to provide control across a number of wafers. In order to maintain synchronization between client, AE and entity requiring the W2W control services, the W2W control capabilities enabled via the Enable service would continue to be enabled until the configuration is changed via the execution of another Enable service request or an event that results in behavior outside the scope of the PCS standard (such as a power cycle or software reset).



SEMI



Phone: 408.943.6900

DRAFT

Document Number:

Equipment

W2W Controller

EquipmentProcessing


PCSAnalyzeRequest(…)

PCSAnalyzeResponse(ControlAdvice, …)

PCSUpdateModelRequest(…)

PCSUpdateModelResponse(…) PCSUpdatemodelResponse(…)

PCSUpdateModelRequest(…)

OR

Figure R2-1 Control Communication Scenario

R2-2.2.1.6 Notification — Figures R2-5 and R2-6 illustrate the communication scenarios to support the Notification step. The PCSInformationLog service is utilized along with the R2R information parameter to communicate information about a particular W2W control PCS Job, such as calculated Control Advice generated, Control Advice used, and process targets. The PCSJobID parameter indicates to which PCS job the information is associated. The PCSInformationLog service can be utilized as a Notification service (Figure R2-5), where the W2W control AE may provide notification at the end of every run (the behavior associated with when the W2W control AE provides this notification is beyond the scope of this Standard). The PCSInformationLog service can also be utilized as a Request service (Figure R2-6), where the requesting agent asks for W2W control information associated with a particular PCSJobID, and the W2W control AE provides that information in the response via the PCSInformationLog parameter.



SEMI



Phone: 408.943.6900

DRAFT

Document Number:

Equipment

W2W Controller

EquipmentProcessing


R2RInformationLogNotification(R2RInformation,PCSJobID, …)

Figure R2-1 Report Communication Scenario via Notification Service

Equipment

W2W Controller

EquipmentProcessing


R2RInformationLogResponse(R2RInformation,PCSJobID, …)

R2RInformationLogRequest(PCSJobID, …)

Figure R2-2 Report Communication Scenario via Request/Response Service



SEMI



Phone: 408.943.6900

DRAFT

Document Number:


PROPOSED PARAMETER DEFINITIONS FOR THE SPC AE TYPE MESSAGES

NOTICE: This Related Information is not an official part of SEMI E133 and was derived from the work of the global Information & Control Technical Committee. This Related Information was approved for publication by full letter ballot procedures on May 13, 2008.

R3-1

[R3-1.1 ] With reference to § 9.7.5 of the Standard, the following Tables (SPC1 through SPC6) describe the proposed data type valuesDataCollections for the SPC input messages:

Table R3-1, SPC1 summarizes the proposed data type valuesDataCollections supported by the PCSAnalyze Message defined in § 9.7.5.2.1.2 of the Standard. The DataItemsDataItemTypes ‘DataChannel,’ ‘Key’ and ‘Aux’ are suggestions for implementers to provide a way to enable the SPC engine to target the sample to the right Channel, Chart and/or Storage and to have a way for grouping the samples. There should be sufficient Context DataItemDataItemType(s) to enable the engine to target the sample.

Table R3-2, SPC2 summarizes the elements for the ParamDef DataItemDataItemTypes defined in Table R3-1, SPC1 and Table R3-3, SPC3.

Table R3-3, SPC3 summarizes the proposed data type valuesDataCollections supported by the PCSStartJob Message defined in § 9.7.5.2.1.2 of the Standard. The PCSStartJob instruction will use all DataItemsDataItemTypes from Table R3-1, SPC1 besides the ParamDef DataItem.DataItemTypes. In addition to those the DataItemsDataItemTypes from Table R3-3, SPC3 below will be used.

Table R3-4, SPC4 summarizes the data type valuesDataCollections supported by the PCSAddMoreData Message defined in § 9.7.5.2.1.2 of the Standard.

Table R3-5, SPC5 summarizes the data type valuesDataCollections supported by the PCSEndJob Message defined in § 9.7.5.2.1.2 of the Standard.

Table R3-6, SPC6 summarizes the data type valuesDataCollections supported by the PCSUpdateModel Message defined in § 9.7.5.2.1.2 of the Standard.

[R3-1.2 ] With reference to § 9.7.6 of the Standard, the following Tables (SPC7–SPC9) describe the proposed data type valuesDataCollections for the SPC output messages:

Table R3-7, SPC7 summarizes the proposed data type valuesDataCollections supported by the PCSAnalyze and PCSEndJob Messages.

Table R3-8, SPC8 summarizes the OOC indicators for out of control actions used by the OOC_nnn DataItemDataItemType defined in table SPC7. The corresponding Western Electric Company Rules (WECO) are mentioned where appropriate.

Table R3-9, SPC9 summarizes additional StatusElement Codes supported by the PCSAnalyze and PCSEndJob Messages.

R3-2 Definitions for the Date and Time Format

[R3-2.1 ] All DataItemsDataItemTypes which refer to a time format shall use the format of the attribute DateTime as defined in SEMI E148 in section Clock Object Attributes.



SEMI



Phone: 408.943.6900

DRAFT

Document Number:

R3-2.1 [R3-2.2 ] The SEMI E148 Standard specifies that the format is according to the ISO 8601:2004 used in the following way:

YYY-MM-DDThh:mm:ss.sTZD,

where:

YYYY is the four-digit year,

MM is the two digit month (01 = January through 12 = December),

DD is the two digit day of month (01 through 31),

T is a special separator character used between date and time,

hh are the two digits of hour (00 through 23),

mm are the two digits of minute (00 through 59),

ss are the two digits of second (00 through 59),

is the separator which is followed by a one or more digits representing a fraction of a second,

s is one or more digits representing a decimal fraction of a second,

TZD is the time zone designator (+hh:mm or -hh:mm)

Example: 2005-07-19T19:20:34.75-05:00

This is: year 2005, July 19th, 7PM, 20 minutes, 34 seconds, 3 quarter of a second, minus five hours from Coordinated Universal Time (UTC), which is Eastern Standard Time.

[Table R3-1 ] SPC1 — Example Data Type Values SupportedDataCollections supported by PCSAnalyze Input (Request) Message to an SPC AE

BinCategoryCollection Type

DataItem Name DataItem Value Description Role#1 Reqd Form

Globals StartDate a UTC time The timestamp of the beginning of the measurement time sample period. This timestamp does not have to reflect the current date. It is allowed to be in the past.

C N DateTime according to SEMI E148 format.



SEMI



Phone: 408.943.6900

DRAFT

Document Number:



Globals FinishDate a UTC time The timestamp of the end of the measurement time sample period. This timestamp does not have to reflect the actual date. It is allowed to be in the past.


AnalysisParameters DataChannel Example:Product_SPC,Process_SPC,Facility_SPC

The unique identification of the data channel to group and store samples for a given SPC application. A channel can also be referred as an instance of a model being utilized for a specific analysis. Within this channel (which corresponds to a name space) the key values are unique and have a meaning.

C N A string identifier which is known and administered in the SPC AE.

AnalysisParameters Key[] Example:Equipment_ID=XYZ3,

Recipe_ID=Etch05,

Lot_ID=BA4711

A given DataChannel has a collection of Key[] identifiers under which a sample is stored in the SPC AE. The key names reflect known identifiers from the application domain.

C N Array of name/value pairs of sample key identifiers.



SEMI



Phone: 408.943.6900

DRAFT

Document Number:



AnalysisParameters Aux[] Example:Pos.X =204,

Pos.Y=25

Aux[] are auxiliary identifiers, which the SPC AE stores together with the sample data, but they are not used for associations and groupings. These could contain detailed information; e.g., the location on the wafer.

C N Array of name/value pairs of auxiliary identifiers.

AnalysisParameters Comment External comment attached to the sample and displayed in the charts.

C N String.

AnalysisParameters DistributionType Normal, Poisson etc.

Distribution type to base limits.

C N String.

AnalysisParameters DisplayRule 0 – never display charts

1 – display affected charts always

2 – display affected charts only in the case that a violation was detected

This is used to override the display rules for charts.

D N Enumeration.

AnalysisParameters RejectFromEval If true, this sample is not taken into SPC evaluations, like a repeated measurement, or a false measurement.

D N Boolean.

AnalysisParameters ParamDef An array of all parameters with their statistical values for this sample.

D Y An array of structured elements from table SPC2.



SEMI



Phone: 408.943.6900

DRAFT

Document Number:

[#1] Where, in the Role column D indicates ‘data’Data’ element and C indicates ‘context.’Context’ element to be used in DataCollections

Table R3-1 [Table R3-2 ] SPC2 — Examples of Structured Elements for ParamDef DataItem

Element Name#3 Element Value Examples

Description Role#1 Reqd Form

Name Thickness,FT-Oxid

Parameter name. D Y String.

Index 1, 2, … Parameter index. D #2 Integer.

Unit ‘nm’,‘in’

Parameter unit. D #2 String.

MeanUCL Externally provided upper control limit for sample mean value.

D #2 Floating point real.

MeanCenter Externally provided center line (expectation value) of sample mean value.


MeanLCL Externally provided lower control limit for sample mean value.


StdevUCL Externally provided upper control limit for sample standard deviation.


StdevCenter Externally provided center line (expectation value) for sample standard deviation.


StdevLCL Externally provided lower control limit for sample standard deviation.


RangeUCL Externally provided upper control limit of sample range.


RangeCenter Externally provided center line (expectation value) of sample range.


RangeLCL Externally provided lower control limit of sample range.


SpecUpper Externally provided upper specification limit. D #2 Floating point real.

SpecTarget Externally provided target value. D #2 Floating point real.

SpecLower Externally provided lower specification limit. D #2 Floating point real.

UpperSpecAvail Upper specification limit exists for this parameter (if false one sided distribution).

D #2 Boolean.

LowerSpecAvail Lower specification limit exists for this parameter (if false one sided distribution).

D #2 Boolean.

UpperAccAvail Upper acceptance limit exists for this parameter.

D #2 Boolean.

LowerAccAvail Lower acceptance limit exists for this parameter.

D #2 Boolean.

SampleSize 1 .. n Sample size for this parameter. D #2 Integer.

Stdev Standard deviation for this parameter. D #2 Floating point real.

Mean Mean value for this parameter. D #2 Floating point real.

Minimum Minimum value for this parameter. D #2 Floating point real.



SEMI



Phone: 408.943.6900

DRAFT

Document Number:

Maximum Maximum value for this parameter. D #2 Floating point real.

Median Median value for this parameter. D #2 Floating point real.


#3[#2] Elements from this table can be required or not required in various combinations dependent on the actual SPC application. At least one element containing a statistical value must be present (e.g., ‘Mean’).

#4[#3] The Element Name list provided here can be extended as necessary to support specific implementations.

[Table R3-3 ] SPC3 — Examples of Additional Data Type Values Supportedadditional DataCollections supported by PCSStartJob Input (Request) Message for an SPC AE



AnalysisParameters ParamDef An array of all parameter names and indexes.

D Y An array of:the structured elements ‘Name’ and ‘Index’ from Table R2-2, SPC2.


[Table R3-4 ] SPC4 — Example Data Type Values SupportedDataCollections supported by PCSAddMoreData Input Message for an SPC AE

Collection TypeBinCategory


Globals RawDate a UTC time The timestamp of the raw value measurement. This timestamp does not have to reflect the actual date. It is allowed to be in the past.


AnalysisParameters StoreFlag Boolean If true, raw values will be stored, otherwise only used for calculation.

C N Boolean.



SEMI



Phone: 408.943.6900

DRAFT

Document Number:

AnalysisParameters RawDataIndex 1 .. n After the PCSStartJob message has occurred, multiple PCSAddMoreData messages for the given PCSJobID may occur. The value is the index (1 .. n) of each successive message.Any PCSAddMoreData message out of the scope of a PCSStartJob and PCSEndJob is not allowed (will be omitted if sent).

C Y Integer.

AnalysisParameters Comment External comment attached to the sample and displayed in the charts.

C N String.

AnalysisParameters FlagExternaly Boolean If true, this sample is not taken into SPC evaluations.

C N Boolean.

AnalysisParameters RawValue_nnn Raw values for the associated parameters.‘nnn’ is replaced with the index number (001, 002, 003, …) of the corresponding parameter index from the previous PCSStartJob message.

D Y Floating point real values.


[Table R3-5 ] SPC5 — Example Data Type Values SupportedDataCollections supported by PCSEndJob Input (Request) Message to an SPC AE



Globals FinishDate a UTC time The timestamp of the end of the sample period. This timestamp does not have to reflect the actual date. It is allowed to be in the past.




SEMI



Phone: 408.943.6900

DRAFT

Document Number:

AnalysisParameters DisplayRule 0 – never display charts1 – display affected charts always2 – display affected charts only in the case that a violation was detected

This is used to override the display rules for charts.

D N Integer.


[Table R3-6 ] SPC6 — Example Data Type Values SupportedDataCollections supported by SPCUpdateModel Input (Request) Message to an SPC AE



AnalysisParameters DataChannel A string identifier which is known and administered in the SPC AE.

Same as in SPC1. C Y String.

ProcessData Key Example: XYZ3,Etch05,BA4711

Same as in SPC1. C Y Array of name/value pairs of sample key identifiers. A minimum of 20 array elements should be supported.

AnalysisParameters ParamDef Example:+0.7,−1.3

An array of all parameter names and new centering values

D Y Array of the structured elements ‘Name’ and ‘Median’ from Table R2-2, SPC2.




SEMI



Phone: 408.943.6900

DRAFT

Document Number:

[Table R3-7 ] SPC7 — Example Data Type Values SupportedDataCollections supported by PCSAnalyze and PCSEndJob Output (Response) Messages

for an SPC AE which Indicates Success



Calculated Outputs OOC_nnn {1, ‘raw above upper spec’, ‘thickness’}

An array of out of control reasons which have occurred for this sample: each OOC_nnn (where nnn is from 001 to the highest OOC).These OOC_nnn codes may be composed of several western electric rule violations and additional violations.

D Y A structure with three elements:– OOC indicator (integer) from SPC8 below– description (string) from Table SPC8 below– ParamDef. Name (string): the name of the parameter of the OOC reason.

[#1] Where, in the Role column D indicates ‘data’Data’ element and C indicates ‘contextContext’ element to be used in DataCollections.’

[Table R3-8 ] SPC8 — An Example Mappingexample mapping of OOC Indicator Codes Used as Fields in Structure for DataItem ValuesDataCollections in Table R3-7, SPC7

OOC#2 Description WECO Reqd

0 Not out of control. Y1 Raw value above upper given specification limit from input

process.N

2 Raw value below lower given specification limit from input process.

N

3 Mean value above upper control limit. N4 Mean value below lower control limit. N5 Standard deviation above upper control limit. N6 Standard deviation below lower control limit. N7 Range above upper control limit. N8 Range below lower control limit. N9 Significantly rising trend over the last n mean values. N10 Significantly falling trend over the last n mean values. N11 High run: last n mean values above center line. N12 Low run: last n mean values below center line. N13 N of M samples in zone A (upper). 2 out of the last 3

points above +2 sigma and below +3 sigma.

N



SEMI



Phone: 408.943.6900

DRAFT

Document Number:

OOC#2 Description WECO Reqd

14 N of M samples in zone A (lower). 2 out of the last 3 points below −2 sigma and above −3 sigma.

N

15 N of M samples in zone A or B (upper). 4 out of the last 5 points above +1 sigma and below +3 sigma.

N

16 N of M samples in zone A or B (lower). 4 out of the last 5 points below −1 sigma and above −3 sigma.

N

17 N samples in zone C (upper and lower). 8 Consecutive Points on one Side of Control Line, below 1 Sigma Limit.

N

18 N samples rising in a row. Trend Rule: 6 in a row trending up.

N

19 N samples falling in a row. Trend Rule: 6 in a row trending down.

N

20 EWMA of mean values above upper control limit. N21 EWMA of mean values below lower control limit. N22 MA of mean values above upper control limit. N23 MA of mean values below lower control limit. N24 Moving standard deviation above upper control limits. N25 Moving standard deviation below lower control limit. N

#1 For an explanation of the Western Electric Company Rules (WECO) see, for example, the NIST/SEMATECH e-Handbook of Statistical Methods; http://www.itl.nist.gov/div898/handbook/, 7/18/2006.

#2 This table can be extended as necessary to support additional control rules including manufacturer specific rules.

Table R3-2 [Table R3-9 ] SPC9 — An Example of Additional StatusElement Codes Supported by PCSAnalyze and PCSEndJob Output (Response) Messages from an SPC AE

Name Code Description Reqd

SUCCESS#1 0 No error—in that case some OOC_nnn DataItems from SPC7 may be included in the message.

Y

SAMPLE_OUT_OF_DATE −32 Sample was not added to the time series of the corresponding channel, since the sample was older than the latest sample in the channel. There can be provisions, which still allow adding samples which are out of date. Such behavior can be enabled/disabled per user administration on the given SPC AE.

N

NO_SPC_CHANNEL_FOUND −33 Sample could not be added to a channel inside SPC AE—no SPC channel found. For further information on SPC channels, see table SPC1.

N

NO_INTERNAL_SPECIFICATION_FOUND −34 Sample could not be added to a channel inside SPC AE—no internal specification found.

N



SEMI



Phone: 408.943.6900

http://www.itl.nist.gov/div898/handbook/

DRAFT

Document Number:

MULTIPLE_SPECIFICATIONS_FOUND −35 Sample could not be added to a channel inside SPC AE—more than one specification found.

N

PARAMETER_OUT_OF_ACCEPTANCE −36 Parameter nnn out of acceptance—sample was not accepted by SPC AE—one of the raw values exceeded the acceptance (plausibility) limits – nnn contained in Attribute Extension.

N

#1 Identified as required in the generic PCS AE specification. No additional specification is provided here.



SEMI



Phone: 408.943.6900

DRAFT

Document Number:


EXAMPLES FOR SPC APPLICATIONS AND AN EXAMPLE FOR XML IMPLEMENTATION

NOTICE: This Related Information is not an official part of SEMI E133 and was derived from the work of the global Information & Control Technical Committee. This Related Information was approved for publication by full letter ballot procedures on May 13, 2008.

R4-1 SPC Use Case Scenarios

R4-1.1 Actors

FICS — The factory information and control system, represents any system in the factory automation environment that needs to make use of the SPC system. This could include manufacturing execution system (MES) equipment control software, PCS framework, or a combination of these items.

SPC AE — The statistical process control analysis engine.

R4-1.2 Pre-Conditions

For R3-1.3 — The SPC AE is initialized and ready to receive PCS AnalysisEngineDataSet messages.

For R3-1.4 — The FICS system in question has established communication (if necessary) with the SPC AE.

R4-1.3 SPC Use Case 1 — Asynchronous, StartJob Message Contains No Data



SEMI



Phone: 408.943.6900

DRAFT

Document Number:

R4-1.4 SPC Use Case 2 — Synchronous, Request Contains Pre-Calculated Data

R4-1.5 SPC Use Case 3 — SPC Data Centering

R4-2 Example for SPC Applications

R4-2.1 Amongst the many SPC uses cases, some generic ones are found very often. In this context, these use cases are referred to as SPC applications (see Table R4-1). Example SPC application keys for the selected SPC applications are given in Table R4-2. Any given PCS engine for SPC may implement any kind of SPC application and those given in Table R4-2 are just example cases.

Table R4-1 Example SPC Applications

Identification of the data channel (refer to

Table R3-2, SPC2)

SPC Application Description of related SPC application

Product_SPC Product SPC Statistical control of product related metrics. This can be used for inline control, functional test or electrical test.

Process_SPC Process SPC Statistical control of process related metrics to ensure process capabilities. This can be used for regular tool checks based for example on reference figures, simulated process results, test (non-product) wafers, or checks for defect density.



SEMI



Phone: 408.943.6900

DRAFT

Document Number:

Equipment_SPC Equipment SPC Statistical control of equipment related metrics not necessarily related directly to products produced with the equipment.

Facility_SPC Facility SPC Statistical control of environmental or facility related metrics. This may include across-fab and nonfab areas.

Table R4-2 Some Example SPC Application Keys

SPC Application KeyValue Comment (see also SEMI International Standards Compilation of Terms)

Product SPC Recipe_Sequence The name of the selected sequence of chamber level recipes.

Recipe_ID ID of chamber level processing recipe.

Lot_ID

Product_ID

Carrier_ID For packaging, ID of carrier holding packages.

ProcessFlow

ProcessStep

Process SPC Equipment_ID Processing Tool.

EquipmentModule Processing Subtool or Chamber ID.

Recipe_ID (Process:The reference process performed on the processing tool).

Equipment SPC Equipment_ID Processing Tool.

EquipmentModule Processing Subtool or Chamber ID.

Recipe_ID The reference process performed on the processing tool.

Facility SPC Location Location description of production area.

R4-3 Example for XML Implementation

R4-3.1 The example below shows a prototypic XML implementation of the use case ‘PCSAnalyze.’

<?xml version="1.0" encoding="UTFutf-8"?>

<AnalysesEngineDataSet>

<PCSAnalyzeIn xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">

<AnalysisEngineDataSet>

<PCSJobID> xmlns="urn:semi-org:xsd.E133.V1115.PCSAE">12abcdef-1234-1234-1234-abcdef123456</PCSJobID>

< <PCSAETargets xmlns="urn:semi-org:xsd.E133.V1115.PCSAE">

<AEType>SPC</AEType>

<AEAlgorithm>3OutOf5</AEAlgorithm>




SEMI



Phone: 408.943.6900

DRAFT

Document Number:

<AEOrder>0</AEOrder>

<Instructions>

<Instruction>PCSAnalyze</Instruction>

<Order>0</Order>

<Status>

<Source>Status source</Source>

<Code>1</Code>

<Description>Status description</Description>

</Status>

</Instructions>

</PCSAETargets>

<DataCollections xmlns="urn:semi-org:xsd.E133.V1115.PCSAE">

<BinCategory>Globals</BinCategory>

<Context>

< <Name>StartDate></Name>

<Value>

<StartDate xmlns="">2008-01-19T19:20:34.75-05:00</StartDate>

< </Value>

</Context>

<Context>

<Name>FinishDate></Name>

<Value>

<FinishDate xmlns="">2008-01-19T19:21:38.00-05:00</FinishDate>

< </Value>

</Context>

<Context>

<Name>DataChannel></Name>

<Value>



SEMI



Phone: 408.943.6900

DRAFT

Document Number:

<DataChannel xmlns="">Product_SPC</DataChannel>

< </Value>

</Context>

<Context>

<Name>Key</Name>

<Value>

<List xmlns="">

<Key>

<Name>Equipment_ID</Name>

<Value>

<Equipment_ID>XYZ3</Equipment_ID>

</Value>

</Key>

<Key>

<Name>Recipe_ID</Name>

<Value>

<Recipe_ID>Etch05</Recipe_ID>

</Value>

</Key>

<Key>

<Name>Lot_ID</Name>

<Value>

<Lot_ID>BA4711</Lot_ID >

</Value>

</Key>

< </List>



SEMI



Phone: 408.943.6900

DRAFT

Document Number:

</Value>

</Context>

<Context>

<Name>Aux</Name>

<Value>

<List xmlns="">

<Aux>

<Name>Pos.X</Name>

<Value>

<Pos.X>204</Pos.X>

</Value>

</Aux>

<Aux>

<Name>Pos.Y</Name>

<Value>

<Pos.Y>25</Pos.Y>

</Value>

</Aux>

< </List>

</Value>

</Context>

<Context>

<Name>Comment></Name>

<Value>

<Comment xmlns="">This is a demo</Comment>

< </Value>



SEMI



Phone: 408.943.6900

DRAFT

Document Number:

</Context>

<Context>

<Name>DistributionType></Name>

<Value>

<DistributionType xmlns="">Normal</DistributionType>

</Value>

</Context>

</Globals>

<AETarget>

<AEType>SPC</AEType>


<Instructions>

<Instruction>PCSAnalyze</Instruction>

</Instructions>

</AETarget>

< </DataCollections>

<DataCollections xmlns="urn:semi-org:xsd.E133.V1115.PCSAE">

<BinCategory>AnalysisParameters</BinCategory>

<Data>

< <Name>DisplayRule></Name>

<Value>

<DisplayRule xmlns="">2</DisplayRule>

< </Value>

</Data>

<Data>

<Name>RejectFromEval></Name>

<Value>

<RejectFromEval xmlns="">false</RejectFromEval>

< </Value>This is a Draft Document of the SEMI International Standards program. No material on this page is to be construed as an official or adopted Standard or Safety Guideline. Permission is granted to reproduce and/or distribute this document, in whole or in part, only within the scope of SEMI International Standards committee (document development) activity. All other reproduction and/or distribution without the prior written consent of SEMI is prohibited.


SEMI



Phone: 408.943.6900

DRAFT

Document Number:

</Data>

<Data>

<Name>ParamDef</Name>

<Value>

<List xmlns="">

<ParamDef>

<Name>Name</Name>

<Value>

<Name>Thickness</Name>

< </Value>

</ParamDef>

<ParamDef>

<Name>Index>1</</Name>

<Value>

<Index>1</Index>

</Value>

</ParamDef>

<ParamDef>

<Name>Unit</Name>

<Value>

<Unit>nm</Unit>

</Value>

</ParamDef>

<ParamDef>

<Name>MeanUCL</Name>

<Value>

<MeanUCL>600</MeanUCL>

</Value>



SEMI



Phone: 408.943.6900

DRAFT

Document Number:

</ParamDef>

<ParamDef>

<Name>MeanCenter</Name>

<Value>

<MeanCenter>500</MeanCenter>

</Value>

</ParamDef>

<ParamDef>

<Name>MeanLCL</Name>

<Value>

<MeanLCL>400</MeanLCL>

</Value>

</ParamDef>

<ParamDef>

<Name>StdevUCL</Name>

<Value>

<StdevUCL>12</StdevUCL>

</Value>

</ParamDef>

<ParamDef>

<Name>StdevCenter</Name>

<Value>

<StdevCenter>8</StdevCenter>

</Value>

</ParamDef>

<ParamDef>

<Name>StdevLCL</Name>

<Value>



SEMI



Phone: 408.943.6900

DRAFT

Document Number:

<StdevLCL>2</StdevLCL>

</Value>

</ParamDef>

<ParamDef>

<Name>RangeUCL</Name>

<Value>

<RangeUCL>20</RangeUCL>

</Value>

</ParamDef>

<ParamDef>

<Name>RangeCenter</Name>

<Value>

<RangeCenter>17</RangeCenter>

</Value>

</ParamDef>

<ParamDef>

<Name>RangeLCL</Name>

<Value>

<RangeLCL>15</RangeLCL>

</Value>

</ParamDef>

<ParamDef>

<Name>SpecUpper</Name>

<Value>

<SpecUpper>550</SpecUpper>

</Value>

</ParamDef>

<ParamDef>



SEMI



Phone: 408.943.6900

DRAFT

Document Number:

<Name>SpecTarget</Name>

<Value>

<SpecTarget>500</SpecTarget>

</Value>

</ParamDef>

<ParamDef>

<Name>SpecLower</Name>

<Value>

<SpecLower>450</SpecLower>

</Value>

</ParamDef>

<ParamDef>

<Name>UpperSpecAvail</Name>

<Value>

<UpperSpecAvail>true</UpperSpecAvail>

</Value>

</ParamDef>

<ParamDef>

<Name>LowerSpecAvail</Name>

<Value>

<LowerSpecAvail>true</LowerSpecAvail>

</Value>

</ParamDef>

<ParamDef>

<Name>UpperAccAvail</Name>

<Value>

<UpperAccAvail>true</UpperAccAvail>

</Value>



SEMI



Phone: 408.943.6900

DRAFT

Document Number:

</ParamDef>

<ParamDef>

<Name>LowerAccAvail</Name>

<Value>

<LowerAccAvail>true</LowerAccAvail>

</Value>

</ParamDef>

<ParamDef>

<Name>SampleSize</Name>

<Value>

<SampleSize>5</SampleSize>

</Value>

</ParamDef>

<ParamDef>

<Name>Stdev</Name>

<Value>

<Stdev>8</Stdev>

</Value>

</ParamDef>

<ParamDef>

<Name>Mean</Name>

<Value>

<Mean>503</Mean>

</Value>

</ParamDef>

<ParamDef>

<Name>Minimum</Name>

<Value>



SEMI



Phone: 408.943.6900

DRAFT

Document Number:

<Minimum>467</Minimum>

</Value>

</ParamDef>

<ParamDef>

<Name>Maximum</Name>

<Value>

<Maximum>523</Maximum>

</Value>

</ParamDef>

<ParamDef>

<Name>Median</Name>

<Value>

<Median>501</Median>

</Value>

</ParamDef>

< </List>

</Value>

</Data>

<Data>

<Name>ParamDef</Name>

<Value>

<List xmlns="">

<ParamDef>

<Name>Name</Name>

<Value>

<Name>FT-Oxid</Name>

</Value>

</ParamDef>



SEMI



Phone: 408.943.6900

DRAFT

Document Number:

<ParamDef>

<Name>Index</Name>

<Value>

<Index>2</Index>

</Value>

</ParamDef>

<ParamDef>

<Name>Unit</Name>

<Value>

<Unit>um</Unit>

</Value>

</ParamDef>

<ParamDef>

<Name>MeanUCL</Name>

<Value>

<MeanUCL>2.5</MeanUCL>

</Value>

</ParamDef>

<ParamDef>

<Name>MeanCenter</Name>

<Value>

<MeanCenter>2</MeanCenter>

</Value>

</ParamDef>

<ParamDef>

<Name>MeanLCL</Name>

<Value>

<MeanLCL>0.5</MeanLCL>



SEMI



Phone: 408.943.6900

DRAFT

Document Number:

</Value>

</ParamDef>

<ParamDef>

<Name>StdevUCL</Name>

<Value>

<StdevUCL>10</StdevUCL>

</Value>

</ParamDef>

<ParamDef>

<Name>StdevCenter</Name>

<Value>

<StdevCenter>6</StdevCenter>

</Value>

</ParamDef>

<ParamDef>

<Name>StdevLCL</Name>

<Value>

<StdevLCL>2</StdevLCL>

</Value>

</ParamDef>

<ParamDef>

<Name>RangeUCL</Name>

<Value>

<RangeUCL>10</RangeUCL>

</Value>

</ParamDef>

<ParamDef>

<Name>RangeCenter</Name>



SEMI



Phone: 408.943.6900

DRAFT

Document Number:

<Value>

<RangeCenter>8</RangeCenter>

</Value>

</ParamDef>

<ParamDef>

<Name>RangeLCL</Name>

<Value>

<RangeLCL>5</RangeLCL>

</Value>

</ParamDef>

<ParamDef>

<Name>SpecUpper</Name>

<Value>

<SpecUpper>2.2</SpecUpper>

<SpecTarget>1</ </Value>

</ParamDef>

<ParamDef>

<Name>SpecTarget</Name>

<Value>

<SpecTarget>1</SpecTarget>

</Value>

</ParamDef>

<ParamDef>

<Name>SpecLower</Name>

<Value>

<SpecLower>0.75</SpecLower>

</Value>

</ParamDef>



SEMI



Phone: 408.943.6900

DRAFT

Document Number:

<ParamDef>

<Name>UpperSpecAvail</Name>

<Value>

<UpperSpecAvail>true</UpperSpecAvail>

</Value>

</ParamDef>

<ParamDef>

<Name>LowerSpecAvail</Name>

<Value>

<LowerSpecAvail>true</LowerSpecAvail>

</Value>

</ParamDef>

<ParamDef>

<Name>UpperAccAvail</Name>

<Value>

<UpperAccAvail>true</UpperAccAvail>

</Value>

</ParamDef>

<ParamDef>

<Name>LowerAccAvail</Name>

<Value>

<LowerAccAvail>true</LowerAccAvail>

</Value>

</ParamDef>

<ParamDef>

<Name>SampleSize</Name>

<Value>

<SampleSize>10</SampleSize>



SEMI



Phone: 408.943.6900

DRAFT

Document Number:

</Value>

</ParamDef>

<ParamDef>

<Name>Stdev</Name>

<Value>

<Stdev>6.78</Stdev>

</Value>

</ParamDef>

<ParamDef>

<Name>Mean</Name>

<Value>

<Mean>2.05</Mean>

</Value>

</ParamDef>

<ParamDef>

<Name>Minimum</Name>

<Value>

<Minimum>1.78</Minimum>

</Value>

</ParamDef>

<ParamDef>

<Name>Maximum</Name>

<Value>

<Maximum>2.19</Maximum>

</Value>

</ParamDef>

<ParamDef>

<Name>Median</Name>



SEMI



Phone: 408.943.6900

DRAFT

Document Number:

<Value>

<Median>2.3</Median>

</Value>

</ParamDef>

</List>

</Value>

</Data>

</ </DataCollections>

AnalysisParameters>


</PCSAnalyzeIn>



SEMI



Phone: 408.943.6900

DRAFT

Document Number:


PCS EVENT NOTIFICATION AND DATA COLLECTION TO PROVIDE A VIRTUAL METROLOGY CAPABILITY

NOTICE: This Related Information is not an official part of SEMI E133 and was derived from the work of the global Information & Control Technical Committee. This Related Information was approved for publication by full letter ballot procedures on December 24, 2011.

R5-1 Overview

R5-1.1 PCS Deployment

R5-1.1.1 Virtual metrology (VM) is defined as the technology of prediction of post process metrology variables (either measurable or nonmeasurable) using process and wafer state information that could include upstream metrology and/or sensor data.5

R5-1.1.2 PCS based applications can be used to help realize VM systems. An example of how a VM system fits alongside other common PCS and nonPCS applications in a semiconductor fab is shown in Figure R5-1. As the VM system is a software system, interaction with the VM system should be via ‘interface B’ capabilities (such as those defined in SEMI E133).

R5-1.1.3 VM systems utilize process and wafer state information as input to the prediction capability. This information could come from a number of sources including data collected directly from the equipment as the processing is occurring (referred to here as ‘trace data’), trace data stored in a database, or trace data processed by a capability such as PCS FD or SPC. VM systems commonly consume FD output from a process as a primary input source, though this input source is often augmented with other sources such as those mentioned above.

R5-1.1.4 An example of the detail of a SEMI E133 compliant PCS system that could be used to realize a VM solution is shown in Figure R5-2. In this example the VM systems consume FD output as an input and thus require interaction with an FD AE. As noted above the VM system may consume inputs from other sources (e.g., dashed line in Figure R5-2); the PCS standard would only directly address interaction with PCS AEs. R2R control AEs can utilize VM output to provide improved capabilities. Thus a SEMI E133 compliant PCS system that will be used to help realize a VM capability should necessarily include both FD and R2R control AEs.

R5-1.1.5 A high level view of typical integration implementations is shown in Figures R5-3 through R5-6; these figures will be explained in more detail later in this Related Information section. Standardized communications are shown to support (1) equipment/process data collection, (2) communication between PCS AE’s, and (3) communication from a PCS AE to non-PCS entities.

R5-1.1.5.1 Equipment/Process Data Collection — Data collection of this type can utilize a number of SEMI Standards, most notably GEM/SECS (SEMI E30) and EDA (SEMI E132/SEMI E134). An example of how GEM/SECS standardized communications can be used to support the data collection can be found in § 4.2.3 and Related Information Section A.4 of SEMI E30. An example of how EDA standardized communications can be used to support the data collection can be found in Related Information 1 of this Standard (SEMI E133).

R5-1.1.5.2 Communication Between PCS AEs — This communication can utilize this PCS (SEMI E133) Standard. This Standard defines the mechanism for PCS AEs to produce and consume messages in order to provide their AE capabilities.

5 For additional information on virtual metrology see: Aftab Khan, James Moyne and Dawn Tilbury “Fab-wide Control Utilizing Virtual Metrology.” (invited) IEEE Trans. on Semiconductor Manufacturing-Special Issue on Advanced Process Control (November 2007): pp. 364-75.This is a Draft Document of the SEMI International Standards program. No material on this page is to be construed as an official or adopted Standard or Safety Guideline. Permission is granted to reproduce and/or distribute this document, in whole or in part, only within the scope of SEMI International Standards committee (document development) activity. All other reproduction and/or distribution without the prior written consent of SEMI is prohibited.


SEMI



Phone: 408.943.6900

DRAFT

Document Number:

R5-1.1.5.3 Communication Between PCS AEs and Non-PCS Components — This communication can utilize this PCS (SEMI E133) Standard. This Standard

defines the mechanism for PCS AEs to produce and consume messages in order to provide their AE capabilities.

Figure R5-1 Example of a VM System as a Component of a Fab-Wide Software Architecture That

Contain SEMI E133 Compliant PCS Components and NonPCS Components

Figure R5-2 Example of a SEMI E133 Compliant PCS System That Could be Used to Realize a VM

Solution(other implementation architectures are allowed; for example the VM system

could consume data such as trace data directly from the data access layer )



SEMI



Phone: 408.943.6900

DRAFT

Document Number:

R5-1.2 Virtual Metrology Implementation Example — VM with Feedback to R2R Control System

R5-1.2.1 The block diagram in Figure R5-3 can represent a typical process that utilizes both FD and R2R control AE capabilities. An information flow diagram describing how the solution could be realized is provided in Figure R5-4. For every wafer n being processed, FD data is collected. An FD AE provides FD data analysis output [v(n)] via SEMI E133 standard messaging. Separately metrology information, when available, y(k), is provided to the R2R control AE via SEMI E133 standard messaging. The R2R controller utilizes this actual metrology information to provide model and subsequent recipe updates u(n) via SEMI E133 standard messaging, usually at a frequency dictated by the frequency of metrology data feedback (e.g., lot to lot).

Figure R5-1 High Level View of Typical Process Utilizing Both FD and R2R Control AE Capabilities

(other implementation architectures are allowed)



SEMI



Phone: 408.943.6900

DRAFT

Document Number:

Figure R5-2 Example of Information Flow for Typical Process Utilizing Both FD and R2R Control AE

Capabilities(other implementation architectures are possible)

R5-1.2.2 The block diagram presented in Figure R5-5 can represent an example of a VM solution to the system of Figures R5-3 and R5-4 that provides feedback to a R2R control system to enable enhanced R2R control capabilities such as W2W control. An information flow diagram describing how the solution could be realized is provided in Figure R5-6. For every wafer n being processed, FD data is collected. An FD AE provides FD data analysis output (v(n)) via SEMI E133 standard messaging. The VM capability utilizes this information and provides a metrology prediction ŷ(n). This prediction is provided to the R2R controller for each wafer via SEMI E133 standard messaging thus providing the R2R control AE with W2W control capabilities. Actually metrology information, when available, y(k), is provided via SEMI E133 standard messaging to both the VM module and the R2R control AE for updating of the VM prediction model (diagonal line) and to provide more precise feedback information to the R2R controller for model updating. The R2R controller utilizes both the VM prediction and (as available) actual metrology information to provide W2W control model and subsequent recipe updates u(n) via SEMI E133 standard messaging.



SEMI



Phone: 408.943.6900

DRAFT

Document Number:

Figure R5-1 High Level View of Typical VM Integration Architecture Where the

VM Solution is Collecting Data from the Equipment FD AE(other implementation architectures are allowed)

Figure R5-2 Example of Information Flow for VM Associated with the Architecture of Figure R5-5

Where the VM System is Providing Feedback to a R2R Control System (other implementation architectures are possible)



SEMI



Phone: 408.943.6900

DRAFT

Document Number:

R5-1.2.3 A high level depiction of information flow associated with VM implementation example of Figures R5-5 and R5-6 is provided in ladder

diagram form in Figure R5-7. The entities involved in the information flow or the posts in the diagram are the equipment a FD AE, a VM system, a R2R control AE and a station controller. Trace data is provided from the equipment to the FD AE via either GEM/SECS (SEMI E30, e.g., see Related Information section A.4) or EDA (e.g., SEMI E132, SEMI E134) communications during a process run or other period of time on the equipment. FD analysis is performed and FD outputs are sent to the VM system via SEMI E133 compliant messages (note that if the VM system is an integral part of the FD system—as depicted in the example of Figure R5-5—then specification of the communications mechanism between the FD and VM components is beyond the scope of this Standard). The VM system uses this information to predict VM values. These values along with appropriate context information such as prediction quality are sent to the R2R control AE via SEMI E133 compliant messages. The R2R control AE uses this information to update R2R control models. At a later time, e.g., when the next wafer is ready for processing, the station controller requests a recipe advice from the R2R controller AE via SEMI E133 compliant messaging and communicates any parameter changes to the equipment via GEM/SECS (SEMI E30, e.g., see Related Information section A.8) compliant messaging.

Figure R5-1 Ladder Diagram Depiction of the Information of the VM Example of Figure R5-4

(other information flow scenarios are possible as described in § R5-1.2.3)This is a Draft Document of the SEMI International Standards program. No material on this page is to be construed as an official or adopted Standard or Safety Guideline. Permission is granted to reproduce and/or distribute this document, in whole or in part, only within the scope of SEMI International Standards committee (document development) activity. All other reproduction and/or distribution without the prior written consent of SEMI is prohibited.


SEMI



Phone: 408.943.6900

DRAFT

Document Number:

R5-1.2.4 R2R control and FD AE’s as well as the VM system can act as servers or clients depending on what task they are executing and how they are implemented. In the example implementation of § R5-1.2.2 the FD and R2R control AE’s as well as the VM system are depicted as operating independently to provide a VM solution with feedback for R2R control. Alternatively these components could all act as servers with information flow orchestrated by a master controller controlling all PCS AEs as well as the VM system. This master controller, for example, could be the ‘strategy engine’ depicted in Figure R5-2. This master controller approach would also be SEMI E133 compliant as long as all messaging directed at achieving PCS capabilities from the PCS system are SEMI E133 compliant.



SEMI



Phone: 408.943.6900

DRAFT

Document Number:

SEMI E133.1-1107

PROVISIONAL SPECIFICATION FOR XML MESSAGING FOR PROCESS CONTROL SYSTEM (PCS)

This standard was technically approved by the global Information & Control Committee. This edition was approved for publication by the global Audits and Reviews Subcommittee on September 5, 2007. It was available at www.semi.org in October 2007 and on CD-ROM in November 2007. Originally published March 2006.

Table of Contents

1 Purpose.......................................................................................................................................79

1.1 XML Implementation Mapping...........................................................................................79

2 Scope...........................................................................................................................................79

2.1 Specification Scope..............................................................................................................79

3 Limitations..................................................................................................................................79

4 Referenced Standards and Documents.......................................................................................79

4.1 SEMI Standards....................................................................................................................79

4.2 OMG Standards....................................................................................................................79

4.3 W3C Standards.....................................................................................................................79

5 Terminology...............................................................................................................................80

5.1 Acronyms and Abbreviations...............................................................................................80

5.2 Definitions............................................................................................................................80

6 Conventions................................................................................................................................80

6.1 Documenting XML Schema With Diagrams.......................................................................80

6.2 XML Schema Sample..........................................................................................................81



SEMI



Phone: 408.943.6900

DRAFT

Document Number:

7 Implementation Overview..........................................................83

7.1 DataCollection......................................................................................................................83

7.2 Point-to-point and Daisy Chain Communication.................................................................83

7.3 Extending the XSD...............................................................................................................83

8 Generic AnalysisEngineDataSet Structure.................................................................................85

9 PCS Core Elements.....................................................................................................................86

9.1 PCSJobIDType.....................................................................................................................86

9.2 PCSAETargetType...............................................................................................................87

9.3 DataType..............................................................................................................................88

9.4 StatusType............................................................................................................................88

9.5 StatusElementType...............................................................................................................89

9.6 AnalysisParametersType......................................................................................................90

9.7 GlobalsType.........................................................................................................................91

9.8 CalculatedOutputType..........................................................................................................92

9.9 LogMessagesType................................................................................................................93

9.10 ModuleDataType................................................................................................................93

9.11 ProcessDataType................................................................................................................93

9.12 SubstrateDataType.............................................................................................................94

10 Request vs. Response AnalysisEngineDataSet Structure.........................................................94

APPENDIX 1 – PCS Aggregate XSD...........................................................................................95



SEMI



Phone: 408.943.6900

DRAFT

Document Number:

1 Purpose

1.1 XML Implementation Mapping

1.1.1 The purpose of this specification is to provide an implementation mapping of the SEMI E133 specification for an Automated Process Control System Interface. This specification does not provide a transport protocol for communication of XML messages between client and server (Analysis Engines).

2 Scope

2.1 Specification Scope

2.1.1 This specification utilizes XML Schema definitions per W3C recommendations.

2.1.2 This specification provides XML Schema mapping of SEMI E133 PCS messages.

NOTICE: This standard does not purport to address safety issues, if any, associated with its use. It is the responsibility of the users of this standard to establish appropriate safety and health practices and determine the applicability of regulatory or other limitations prior to use.

3 Limitations

3.1 This document represents an XML aggregation model for PCS messaging. Additional specification will be necessary to represent concepts in SEMI E133 that are not covered by the current model.

[3.2 ] This is a provisional specification. In order to have the provisional status removed, the following items must be completed.

SEMI E133 must have its provisional status removed.

This specification must provide XML Schema mapping for the specific R2R, SPC, FD, FC, FP functional groups.

[4 ] Referenced Standards and Documents

1: Definitions or descriptions of the following terms used in this specification may be found in the SEMI Compilation of Abbreviations and Acronyms, available on the SEMI web site, http://www.semi.org.

3.2 [4.1 ] SEMI Standards

SEMI E133 — Provisional Specification for Automated Process Control Systems Interface

3.3 [4.2 ] OMG Standards

Unified Modeling Language (UML) Specification, Version 1.4, OMG Specification 01-09-67; http://www.omg.org/technology/documents/modeling_spec_catalog.htm

3.4 [4.3 ] W3C Standards

Extensible Markup Language (XML) 1.0 (Second Edition) – W3C, 6 October 2000; http://www.w3c.org/TR/2000/REC-xml-20001006/

Namespaces in XML – W3C, 14 January 1999; http://www.w3c.org/TR/1999/REC-xml-names-19990114/

XML Schema Part 0: Primer – W3C, 2 May 2001; http://www.w3c.org/TR/xmlschema-0/

XML Schema Part 2: Datatypes – W3C, 2 May 2001; http://www.w3c.org/TR/xmlschema-2/

XML Schema Part 0: Primer – W3C, 2 May 2001; http://www.w3c.org/TR/xmlschema-0/

XML Path Language (Xpath) – W3C, 16 November 1999; http://www.w3c.org/TR/xpath/



SEMI



Phone: 408.943.6900

http://www.w3c.org/TR/xpath/

http://www.w3c.org/TR/xmlschema-0/



http://www.w3c.org/TR/1999/REC-xml-names-19990114/

http://www.w3c.org/TR/2000/REC-xml-20001006/

http://www.w3c.org/TR/2000/REC-xml-20001006/

http://www.omg.org/technology/documents/modeling_spec_catalog.htm

http://www.omg.org/technology/documents/modeling_spec_catalog.htm

http://www.semi.org/

DRAFT

Document Number:

NOTICE: Unless otherwise indicated, all documents cited shall be the latest published versions.



SEMI



Phone: 408.943.6900

DRAFT

Document Number:

4 [5 ] Terminology2: Terminology is defined as acronyms, abbreviations and term definitions.

4.1 [5.1 ] Abbreviations and Acronyms

The following acronyms and abbreviations are unique to this standard.

4.1.1 [5.1.1 ] UML — Unified Modeling Language

4.1.2 [5.1.2 ] W3C — World Wide Web Consortium

4.1.3 [5.1.3 ] XSD — XML Schema Definition

4.1.4 [5.1.4 ] See also SEMI E133 for additional acronyms

4.2 [5.2 ] Definitions

4.2.1 [5.2.1 ] No additional term definitions are unique to this standard.

5 [6 ] Conventions

5.1 [6.1 ] Documenting XML Schema with Diagrams

5.1.1 [6.1.1 ] This document provides graphical representations of the included XML Schema data type and element definitions. Although no standard graphical notation for XML Schema could be found, various XML tools have their own notation. This document will use the notation provided by XMLSpy from Altova Corporation Figure 1 shows a sample XML Schema diagram that will be used to provide a basis for explanation of the schema graphical notation used in the rest of the document.



SEMI



Phone: 408.943.6900

DRAFT

Document Number:

Figure 1XML Schema Example Diagram

5.1.2 [6.1.2 ] In the diagram, rectangular boxes represent XML element definitions. Ownership or containment is read from right to left in the diagrams. In the sample diagram, ParentType contains Child1, Child2, Child 3, and Child 4. In turn, Child2 contains Child2a, Child2b, and Child2c. The additional symbols (8-sided boxes) represent sequences or choices. See Table 1 for an explanation of these symbols.

Table 1 Altova XMLSPY Schema Diagram Symbols

Denotes a required ordered sequence of the right hand elements with a cardinality of one for each element. (sequence)

Denotes an optional ordered sequence of the right hand elements with a cardinality of one for each element. (sequence)

Denotes a required, but unordered, sequence of the right hand elements with a cardinality of one for each element. (all)

Denotes a required choice of the right hand elements. Exactly one or two of the right hand elements must be present. (choice)

Name Denotes an element.

NameName Denotes an element that contains parsed character data.

5.1.3 [6.1.3 ] A graphic using a solid line is a required element; using a dashed line represents an optional element. Numbers or ranges in the lower right hand corner represent cardinality. The default cardinality is one.

5.1.4 [6.1.4 ] To simplify a diagram or help focus on a particular aspect, detail may be hidden. The 8-sided symbols have a small square on the right end. If a minus sign “-” is in the box, then all detail is shown. If the box contains a plus sign “+”, then all detail to the right of that symbol is hidden. The example has no hidden detail.

5.1.5 [6.1.5 ] The yellow (or gray if printed in monochrome) boxes indicate the use of other defined types. So, Child4 is of type “Child4Type”. Child4Type defines Child4a and Child4b. This detail may be hidden in the diagram. Object oriented inheritance is typically represented in XML as type extension. In Figure 1, ParentType extends Child1and2Type by adding a sequence that includes Child3 and Child4.

5.1.6 [6.1.6 ] Reading Figure 1 would yield the following additional information:

1. Child1and2Type is an ordered sequence of two items: Child2 and Child1.

2. Child1 contains an optional ordered sequence of Child1a, one or more Child1b, and (optionally) Child1c.

3. Child2 contains a choice of one or two of the following: Child2a, Child2b, and Child2c.

4. Child3 contains an unordered sequence of Child3a and Child3b.

5.2 [6.2 ] XML Schema Sample

5.2.1 [6.2.1 ] The sample XML Schema for the example shown in Figure 1, is presented below.



SEMI



Phone: 408.943.6900

DRAFT

Document Number:

<?xml version="1.0" encoding="UTF-8"?>

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified">

<xs:element name="parentType">

<xs:complexType>

<xs:complexContent>

<xs:extension base="Child1and2Type">

<xs:sequence>

<xs:element name="Child3">

<xs:complexType>

<xs:all>

<xs:element name="Child3a"/>

<xs:element name="Child3b"/>

</xs:all>

</xs:complexType>

</xs:element>

<xs:element name="Child4" type="Child4Type"/>

</xs:sequence>

</xs:extension>

</xs:complexContent>

</xs:complexType>

</xs:element>

<xs:complexType name="Child1and2Type">

<xs:sequence>


<xs:complexType>

<xs:choice maxOccurs="2">


<xs:element name="Child2b"/>



SEMI



Phone: 408.943.6900

DRAFT

Document Number:

<xs:element name="Child2c"/>

</xs:choice>

</xs:complexType>

</xs:element>


<xs:complexType>

<xs:sequence>


<xs:element name="Child1b" maxOccurs="unbounded"/>

<xs:element name="Child1c" minOccurs="0"/>

</xs:sequence>

</xs:complexType>

</xs:element>

</xs:sequence>

</xs:complexType>

<xs:complexType name="Child4Type">

<xs:sequence>

<xs:element name="Child4a" type="xs:string"/>

<xs:element name="Child4b" type="xs:string"/>

</xs:sequence>

</xs:complexType>

</xs:schema>

Figure 2XML for Sample



SEMI



Phone: 408.943.6900

DRAFT

Document Number:

6 [7 ] Implementation Overview

[7.1 ] DataCollection

[7.2 ] The SEMI E133 specification suggests that an Element ‘DataCollection’ exists with an attribute of ‘BinCategory’. To allow for XML validating parsers to work with the XSD and instance XML, the DataCollection element is not used. Instead, the name of the XSD overview

6.1.1 The XSD is documented in the E133-1-V0717-PCSAE-Schema.xsd file. This file is the authoritative definition of E133.1. This document elaborates on the purpose and use of the structures defined in the E133-1-V0717-PCSAE-Schema.xsd file.

6.1.2 BinCategory is used as the element name. For example, we use:

<Globals>

<item1>123</item1>

<item2>ABC</item2>

</Globals>

Instead of:

<DataCollection BinCategory=”Globals”>

<item1>123</item1>

<item2>ABC</item2>

</DataCollection>

[7.2.1 ] This allows the following to be enforced:

Order using xs:sequence to ensure Globals is before ModuleData, etc.

Children can be validated for structure and content.

[7.3 ] Point-to-point and Daisy Chain Communication

6.1.3 [7.3.1 ] Point-to-point communication represents one client communicating to one server. In extending the XSD in this document, a closed form XSD can be defined for request and response XML instances.

[7.3.2 ] Daisy chain communication is where one client communicates to one server, and that server communicates to an additional server, and so on and so forth. It is left to the field implementation to coordinate the XSDs that are passed from clients and servers and how data is passed through from upstream servers back to the client.The PCSAETargetType.AEOrder and the PCSAEInstructionType.Order fields are provided to coordinate the daisy chaining order between separate PCSAE services or within a single PCSAE service instance.

6.2 [7.4 ] Extending the XSD



SEMI



Phone: 408.943.6900

DRAFT

Document Number:

6.2.1 [7.4.1 ] This document does not provide a complete XSD form for use in a specific application. Instead, ‘Data’, ‘Context’ and ‘Extension’ elements are

used as placeholders for additional structure to be implemented in the field.

6.2.2 [7.4.2 ] For example, if ‘SomeDataType’ within this schema has the following definition:

Figure 3Generic XML Schema Diagram for SomeDataType

6.2.3 [7.4.3 ] The actual implementation of ‘SomeDataType’ would add elements under Context and/or Data specific to that application such as:

Figure 4Application Specific XML Schema Diagram for SomeDataType

6.2.4 [7.4.4 ] SomeDataType now requires that <Context> and <Data> elements are present. It also requires specific child elements for <Context> and <Data> with specific data types in order. All instances of the ’Context’, ‘Data’ and ‘Extension’ elements within this specification shall be modified in a similar manner.

6.2.5 [7.4.5 ]



SEMI



Phone: 408.943.6900

DRAFT

Document Number:

Figure 5Application Specific XML Schema for SomeDataType

7 [8 ] Generic AnalysisEngineDataSet Structure

7.1 [8.1 ] The following requirements define a generic AnalysisEngineDataSet. This XML Schema definition (XSD) can be used for validatation of any XML message for compliance to this specification. This XSD does not impose further restrictions required by functional group or requests and responses.



SEMI



Phone: 408.943.6900

DRAFT

Document Number:

Figure 6

7.2 [8.2 ] The AnalysisEngineDataSet has the following ordered child elements:



SEMI



Phone: 408.943.6900

DRAFT

Document Number:

Element Name Type Min Occurs Max Occurs

PCSJobID PCSJobIDType 0 1

PCSAETarget PCSAETargetType 0 Unbounded

Status StatusType 0 1

Globals GlobalsType 0 1

AnalysisParametersDataCollections

AnalysisParametersTypeDataCollectionType

0 1

CalculatedOutputs CalculatedOutputType 0 1

LogMessages LogMessagesType 0 1

ModuleData ModuleDataType 0 1

ProcessData ProcessDataType 0 1

SubstrateData SubstrateDataType 0 1

8 [9 ] PCS Core Elements

3: The following defines the PCS core elements. The core elements may be extended by future versions of this document.

8.1 [9.1 ] PCSJobIDType

8.1.1 [9.1.1 ] The PCSJobIDType is used to define the schema requirements for the PCSJobID element. The following is the definition:

Type Restriction Base Enumerations

xs:simpleType xs:string Not Applicable



SEMI



Phone: 408.943.6900

DRAFT

Document Number:

8.2 [9.2 ] PCSAETargetType

Figure 7

[9.2.1 ] The PCSAETargetType is used to define the schema requirements for ana PCSAETarget not associated with a functional group in the instance XML. Note that PCSAEType is an optional child element in the PCSAETarget element. Also, the. The ‘Extension’ element is to be used to add additional information as child elements under this element.

Element Name Type Model Min Occurs Max Occurs Enumerations

PCSAETypeAEType

xs:stringAETypeSelector

NA 01 1 PCS, R2R, FDD, FCC, FPP, SPC, etc.

AEAlgorithm xsd:string NA 1 1 NA

AEInstance xsxsd:int NA 01 1 NAThis is a Draft Document of the SEMI International Standards program. No material on this page is to be construed as an official or adopted Standard or Safety Guideline. Permission is granted to reproduce and/or distribute this document, in whole or in part, only within the scope of SEMI International Standards committee (document development) activity. All other reproduction and/or distribution without the prior written consent of SEMI is prohibited.


SEMI



Phone: 408.943.6900

DRAFT

Document Number:

InstructionsAEOrder

xs:complexxsd:int xs:sequenceNA 1 1 NA

Status StatusElementType NA 1 1 NA

Instruction xs:stringPCSAEInstructionType

NA 1 Unbounded NA

Extension xs:complex xs:sequence 0 1 NA

8.3 [9.3 ] DataType

Figure 8

[9.3.1 ] The DataType is used to define a generic Data element containing the results from an analysis engine. This type is used for ‘Context’ and ‘Data’ elements. AdditionalThe structure of DataType allows for extension of the Value node to support additional child elements can be added for field implementation of specific applications.



SEMI



Phone: 408.943.6900

DRAFT

Document Number:

Element Name Type Model Min Occurs Max Occurs

DataItem DataItemType Not Applicable 1 1

8.4 [9.4 ] StatusType

Figure 9

8.4.1 [9.4.1 ] The StatusType defines the Status attribute. Note that the StatusType is implemented as a XML element instead of an XML attribute. The StatusType is a xs:complexType with a xs:sequence model. The StatusType has the following ordered child elements:


StatusElement StatusElementType NA 1 unbounded

8.5 [9.5 ] StatusElementType



SEMI



Phone: 408.943.6900

DRAFT

Document Number:

Figure 10

8.5.1 [9.5.1 ] The StatusElementType defines the StatusElement. Note that the StatusElement is implemented as a XML element instead of an XML attribute. The StatusElement is a xs:complexType with a xs:sequence model. The StatusElement has the following ordered child elements:


Source xs:string NA 01 1

Code xs:int NA 1 1

Description xs:string NA 01 1



SEMI



Phone: 408.943.6900

DRAFT

Document Number:

Extension DataItemTypexs:complexType

xs:sequenceNA 0 1

8.5.2 [9.5.2 ] The Extension element is used by field implementations to add additional child elements.

8.6 [9.6 ] AnalysisParametersType

Figure 11

[9.6.1 ] The AnalysisParametersType definesDataCollectionsdefines the generic AnalysisParameters BinCategory. The AnalysisParametersType isDataCollectionsis a xs:complexType with a xs:sequence model and a cardinality minimum of 1 and maximum of 23 child elements. The AnalysisParametersType hasDataCollectionshas the following ordered child elements:


BinCategor BinCategoryTyp NA 01 1



SEMI



Phone: 408.943.6900

DRAFT

Document Number:

yContext eDataItemType

Data DataItemType NA 0 1

[9.7 ] GlobalsType

[Figure 6]

[9.7.1 ] The GlobalsType defines the generic Globals BinCategory. The GlobalsType is a xs:complexType with a xs:sequence model and a cardinality minimum of 1 and maximum of 1 child elements. The GlobalsType has the following child element:


Context DataItemType NA 1 1

[9.8 ] CalculatedOutputType

[Figure 7]

[9.8.1 ] The CalculatedOutputType defines the generic CalculatedOutput BinCategory. The CalculatedOutputType is a xs:complexType with a xs:sequence model and a cardinality minimum of 1 and maximum of 2 child elements. For R2R control advise, the ControlAdvise element shall be used to return data. This element shall contain child elements that are to be field configured to meet the needs of the specific application. The CalculatedOutputType has the following ordered child elements:






SEMI



Phone: 408.943.6900

DRAFT

Document Number:

ControlAdvise DataItemType NA 0 1



SEMI



Phone: 408.943.6900

DRAFT

Document Number:

[9.9 ] LogMessagesType

[Figure 8]

[9.9.1 ] The LogMessagesType defines the generic LogMessages BinCategory. The LogMessagesType is a xs:complexType with a xs:sequence model and a cardinality minimum of 1 and maximum of 2 child elements. The LogMessagesType has the following ordered child elements:




[9.10 ] ModuleDataType

[Figure 9]

[9.10.1 ] The ModuleDataType defines the generic ModuleData BinCategory. The ModuleDataType is a xs:complexType with a xs:sequence model and a cardinality minimum of 1 and maximum of 2 child elements. The ModuleDataType has the following ordered child elements:




[9.11 ] ProcessDataType



SEMI



Phone: 408.943.6900

DRAFT

Document Number:

[Figure 10]

[9.11.1 ] The ProcessDataType defines the generic ProcessData BinCategory. The ProcessDataType is a xs:complexType with a xs:sequence model and a cardinality minimum of 1 and maximum of 2 child elements. The ProcessDataType has the following ordered child elements:




[9.12 ] SubstrateDataType

[Figure 11]

[9.12.1 ] The SubstrateDataType defines the generic SubstrateData BinCategory. The SubstrateDataType is a xs:complexType with a xs:sequence model and a cardinality minimum of 1 and maximum of 2 child elements. The SubstrateDataType has the following ordered child elements:




[10 ] Request vs. Response AnalysisEngineDataSet Structure

[10.1 ] There is a small difference in the required elements for a request vs. a response that utilize the Generic AnalysisEngineDataSet specified above. A response shall contain a PCSJobID element. Otherwise, a response is identical to a Generic AnalysisDataSet Structure. The table below details the difference.



SEMI



Phone: 408.943.6900

DRAFT

Document Number:

Submission Type Element Name Type Min Occurs Max Occurs

Request PCSJobID PCSJobIDType 0 1

Response PCSJobID PCSJobIDType 1 1

Request/Response {All other elements identical to generic structure}



SEMI



Phone: 408.943.6900

DRAFT

Document Number:

APPENDIX 1

PCS AGGREGATE XSD

NOTICE: The material in this appendix is an official part of SEMI E133.1 and was approved by full letter ballot procedures on November 29, 2005. The appendix contains the XSD representing the core elements use to make valid AnalysisEngineDataSet’s

<?xml version="1.0" encoding="UTF-8"?>

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified">

<xs:simpleType name="PCSJobIDType">

<xs:annotation>

<xs:documentation>A unique identifier of a Process Control System Job</xs:documentation>

</xs:annotation>

<xs:restriction base="xs:string"/>

</xs:simpleType>

<xs:complexType name="PCSAETargetType">

<xs:annotation>

<xs:documentation>PCSAETarget for PCS messages</xs:documentation>

</xs:annotation>

<xs:sequence>

<xs:element name="PCSAEType">

<xs:simpleType>

<xs:restriction base="xs:string">

<xs:enumeration value="PCS"/>

<xs:enumeration value="R2R"/>

<xs:enumeration value="FDD"/>

<xs:enumeration value="FCC"/>

<xs:enumeration value="FPP"/>

<xs:enumeration value="SPC"/>

</xs:restriction>



SEMI



Phone: 408.943.6900

DRAFT

Document Number:

</xs:simpleType>

</xs:element>

<xs:element name="AEInstance" type="xs:int" minOccurs="0"/>

<xs:element name="Instructions">

<xs:complexType>

<xs:sequence>

<xs:element name="Instruction" maxOccurs="unbounded">

<xs:simpleType>

<xs:restriction base="xs:string">

<xs:enumeration value="PCSUpdateModel"/>

<xs:enumeration value="PCSAnalyze"/>

</xs:restriction>

</xs:simpleType>

</xs:element>

</xs:sequence>

</xs:complexType>

<xs:unique name="UniquePCSInstruction">

<xs:selector xpath=".//Instruction"/>

<xs:field xpath="."/>

</xs:unique>

</xs:element>

<xs:element name="Extension" minOccurs="0">

<xs:complexType/>

</xs:element>

</xs:sequence>

</xs:complexType>

<xs:complexType name="DataItemType">

<xs:annotation>

<xs:documentation>Data Type</xs:documentation>

</xs:annotation>



SEMI



Phone: 408.943.6900

DRAFT

Document Number:

</xs:complexType>

<xs:complexType name="DataR2RType">

<xs:annotation>

<xs:documentation>Data Type</xs:documentation>

</xs:annotation>

<xs:sequence minOccurs="0">

<xs:element name="ControlAdvise" type="DataItemType" minOccurs="0"/>

</xs:sequence>

</xs:complexType>

<xs:complexType name="AnalysisParametersType" final="#all">

<xs:annotation>

<xs:documentation>AnalysisParameters BinCategory</xs:documentation>

</xs:annotation>

<xs:sequence maxOccurs="2">

<xs:element name="Context" type="DataItemType" minOccurs="0"/>

<xs:element name="Data" type="DataItemType" minOccurs="0"/>

</xs:sequence>

</xs:complexType>

<xs:complexType name="GlobalsType" final="#all">

<xs:annotation>

<xs:documentation>Globals BinCategory</xs:documentation>

</xs:annotation>

<xs:sequence>

<xs:element name="Context" type="DataItemType"/>

</xs:sequence>

</xs:complexType>

<xs:complexType name="CalculatedOutputType" final="#all">

<xs:annotation>

<xs:documentation>CalculatedOutput BinCategory for R2R messages</xs:documentation>



SEMI



Phone: 408.943.6900

DRAFT

Document Number:

</xs:annotation>



<xs:element name="Data" type="DataR2RType" minOccurs="0"/>

</xs:sequence>

</xs:complexType>

<xs:complexType name="LogMessagesType" final="#all">

<xs:annotation>

<xs:documentation>LogMessage BinCategory</xs:documentation>

</xs:annotation>




</xs:sequence>

</xs:complexType>

<xs:complexType name="ModuleDataType" final="#all">

<xs:annotation>

<xs:documentation>ModuleData BinCategory</xs:documentation>

</xs:annotation>




</xs:sequence>

</xs:complexType>

<xs:complexType name="ProcessDataType" final="#all">

<xs:annotation>

<xs:documentation>ProcessData BinCategory</xs:documentation>

</xs:annotation>





SEMI



Phone: 408.943.6900

DRAFT

Document Number:


</xs:sequence>

</xs:complexType>

<xs:complexType name="SubstrateDataType" final="#all">

<xs:annotation>

<xs:documentation>SubstrateData BinCategory</xs:documentation>

</xs:annotation>




</xs:sequence>

</xs:complexType>

<xs:complexType name="StatusType">

<xs:annotation>

<xs:documentation>Status</xs:documentation>

</xs:annotation>

<xs:sequence>

<xs:element name="StatusElement" type="The E133-1-V0717-PCSAE-Schema.xsd file is the authoritative definition of the E133.1 XSD. This file is attached as a reference document and not included in this document to ensure that there is one and only one authoritative source for the E133.1 XSD.

StatusElementType" maxOccurs="unbounded"/>

</xs:sequence>

</xs:complexType>

<xs:complexType name="StatusElementType">

<xs:annotation>

<xs:documentation>StatusElement</xs:documentation>

</xs:annotation>

<xs:sequence>

<xs:element name="Source" type="xs:string" minOccurs="0">

<xs:annotation>



SEMI



Phone: 408.943.6900

DRAFT

Document Number:

<xs:documentation>Represents the document where code is generated from</xs:documentation>

</xs:annotation>

</xs:element>

<xs:element name="Code" type="xs:int" block="#all">

<xs:annotation>

<xs:documentation>Status Code</xs:documentation>

</xs:annotation>

</xs:element>

<xs:element name="Description" type="xs:string" minOccurs="0">

<xs:annotation>

<xs:documentation>This is a human readable description of the status</xs:documentation>

</xs:annotation>

</xs:element>

<xs:element name="Extension" minOccurs="0">

<xs:annotation>

<xs:documentation>For supplier to provide more information</xs:documentation>

</xs:annotation>

<xs:complexType final="#all"/>

</xs:element>

</xs:sequence>

</xs:complexType>

<xs:element name="AnalysisEngineDataSet">

<xs:complexType>

<xs:sequence>

<xs:element name="PCSJobID" type="PCSJobIDType" minOccurs="0"/>

<xs:element name="PCSAETarget" type="PCSAETargetType" minOccurs="0" maxOccurs="unbounded"/>

<xs:element name="Status" type="StatusType" minOccurs="0"/>

<xs:element name="Globals" type="GlobalsType" minOccurs="0"/>This is a Draft Document of the SEMI International Standards program. No material on this page is to be construed as an official or adopted Standard or Safety Guideline. Permission is granted to reproduce and/or distribute this document, in whole or in part, only within the scope of SEMI International Standards committee (document development) activity. All other reproduction and/or distribution without the prior written consent of SEMI is prohibited.


SEMI



Phone: 408.943.6900

DRAFT

Document Number:

<xs:element name="AnalysisParameters" type="AnalysisParametersType" minOccurs="0"/>

<xs:element name="CalculatedOutputs" type="CalculatedOutputType" minOccurs="0"/>

<xs:element name="LogMessages" type="LogMessagesType" minOccurs="0"/>

<xs:element name="ModuleData" type="ModuleDataType" minOccurs="0"/>

<xs:element name="ProcessData" type="ProcessDataType" minOccurs="0"/>

<xs:element name="SubstrateData" type="SubstrateDataType" minOccurs="0"/>

</xs:sequence>

</xs:complexType>

</xs:element>

</xs:schema>

NOTICE: SEMI makes no warranties or representations as to the suitability of the Standards and Safety Guidelines set forth herein for any particular application. The determination of the suitability of the Standard or Safety Guideline is solely the responsibility of the user. Users are cautioned to refer to manufacturer’s instructions, product labels, product data sheets, and other relevant literature, respecting any materials or equipment mentioned herein. Standards and Safety Guidelines are subject to change without notice.

By publication of this Standard or Safety Guideline, SEMI takes no position respecting the validity of any patent rights or copyrights asserted in connection with any items mentioned in this Standard or Safety Guideline. Users of this Standard or Safety Guideline are expressly advised that determination of any such patent rights or copyrights and the risk of infringement of such rights are entirely their own responsibility.

<end of ballot>



SEMI



Phone: 408.943.6900