semi合集-English.pdf - 第3424页

SEMI E133-0705 © SEMI 2004, 2005 5 Table 3 Method Defini tion Table Format # Method Arguments Returns Re quirement Behavior/Comment Y or N 7.2.9.1 Method — Method name. 7.2.9.2 Arguments — Input parameters. 7.2.9.3 Retur…

SEMI E133-0705 © SEMI 2004, 2005 4

7.2.3 Class Diagrams — UML Class Charts.

7.2.4 Name of a Class — The text capitalizes 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

Y or N 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), the concept of access does not apply and “Not Applicable” (NA) is used in the Access field.

7.2.6.2 Reqd — Is this attribute required? Y — Yes, or N — No.

7.2.6.3 Form — Defines the data type of the attribute. Data types specified in the Process Control Systems

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 Process Control

System interface specifications are not limited to the list of data types defined in this specification. See the

definition of “Form” in the SEMI Compilation of Terms for other Form values commonly used in SEMI documents.

7.2.6.4 Constraints

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.

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.2.9 Method Definition — The methods (in other words, the messages that comprise the external interface to an

object) supported by a PCS functional group are defined in table format as illustrated below.

SEMI E133-0705 © SEMI 2004, 2005 5

Table 3 Method Definition Table Format

# Method Arguments Returns Requirement Behavior/Comment

Y or N

7.2.9.1 Method — Method name.

7.2.9.2 Arguments — Input parameters.

7.2.9.3 Returns — Output parameters.

7.2.9.4 Requirement — Is this method required of a compliant implementation? Y – Yes, or N – No.

7.2.9.5 Behavior/Comment — Summary description of the method’s purpose and behavior, explanation of expected

system response to this method, etc.

7.3 Data Types

7.3.1 The following data types may be used in this specification to describe the form of an attribute or other similar

high level definitions. Note that extensions to the Process Control System 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).

 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.

 Integer — 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. 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 — 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 Sequence Behavior

7.4.1 Sequence behavior description is specified in the form of UML Sequence Diagrams.

7.5 State Behavior

7.5.1 State behavior description is specified in the form of UML State Charts.

8 Overview

8.1 Using the simple definition of a Functional Group given in the Terminology section, the initial set of PCS

functional groups has been identified. To identify the proper scope (and therefore the boundaries) for these groups,

SEMI E133-0705 © SEMI 2004, 2005 6

the following criteria are applied to test whether or not a given set of capabilities constitutes a valid PCS functional

group. Specifically, a functional group 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 (for example, the capabilities are inseparable because an

external system must interact with them as an integrated whole)

 Strong associations exist in the market (that is, one would expect these capabilities to be provided as an

integrated product)

8.2 Based on theses criteria, and the stated implementation priorities of the semiconductor manufacturers and

suppliers involved on the task force, the following initial PCS functional groups have been identified:

 R2R (Run-to-Run) Control

 FD (Fault Detection)

 FC (Fault Classification)

 FP (Fault Prediction)

 SPC (Statistical Process Control)

8.3 Note that it is understood that other PCS functional groups can be added as needed. Future versions of the

document will describe procedures for adding a new group.

8.4 The aforementioned groups can be implemented at the tool or factory level or both. As a requirement,

functional group interfaces should be defined in a consistent way. The following diagram represents the proposed

functional groups and an example of their interactions within the factory and tool environments.

PCS Functions in the “Equipment”

R2R FD FC FP SPC ...

Equipment Specific

Tool Control System

- Process Modules

- Integrated Metrology

- Sensors

- User Interface

- E-Diagnostics

- ...

PCS Functions in the “Factory”

R2R

R2R FD FC FP SPC ...

Factory Specific

Manufacturing Execution Systems

- Recipe Management

- Dispatch

- Automated Material Handling

- E-Diagnostics

- ...

PCS Functions in the “Equipment”

R2R FD FC FP SPC ...

Equipment Specific

Tool Control System

- Process Modules

- Integrated Metrology

- Sensors

- User Interface

- E-Diagnostics

- ...

Figure 1

PCS Functions

8.4.1 Process Control Systems 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 above, several run-to-run controllers are running at the factory level with

differences that are only visible as internal special capabilities. 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.