semi合集-English.pdf - 第3581页

SEMI E139-0705 © SEMI 2005 5 5 Terminology 5.1 SEM I Compila tion of Ter ms 5.1.1 Definitions or descripti ons of ma ny of the term s used in this specification can be found i n the SEMI Compilati on of Terms, available …

SEMI E139-0705 © SEMI 2005 4

details are not specified, but the required function of the interface is defined. This will be further explained later in

the document.

2.3 In summary, these are the interfaces that are specified in this document:

 FICS  Equipment – full messaging services

 FICS  PDE/Recipe Editor – full messaging services

 Equipment  PDE/Recipe Editor – functional requirements only

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 The following items are out of scope and are not specified in this document:

 The content or format of the PDEbody.

 The message format and communication details of message services.

 How PDEs are used or executed within the equipment.

 How the FICS initiates execution of PDEs within the equipment.

 How and when the parameter values are communicated to the equipment.

 How data is collected to document what PDEs and parameter values were used in a specific situation.

 The interactions between a human user and the PDE/Recipe Editor.

 Design of FICS applications (for example, Station Controller and PDE/Recipe Manager as shown in Figure 1).

These applications are shown to enhance the clarity of the content of this specification.

4 Referenced Standards and Documents

4.1 SEMI Standards

SEMI E5 — SEMI Equipment Communication Standard 2 (SECS-II)

SEMI E30 — Generic Model for Communications and Control of SEMI Equipment (GEM)

SEMI E40 — Standard for Process Job Management (PJM)

SEMI E120 — Common Equipment Module (CEM)

4.2 ISO Standards

uuid: ISO/IEC 11578:1996 Information technology - Open Systems Interconnection – Remote Procedure Call

(RPC), http://www.iso.ch/cate/d2229.htm.

4.3 OMG Standards

Unified Modeling Language (UML) Specification, Version 1.4, OMG Specification 01-09-67, available from

http://www.omg.org/technology/documents/modeling_spec_catalog.htm.

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

1 Semiconductor Equipment and Materials International (SEMI), 3081 Zanker Road, San Jose, CA 95134, 408.943.6900, FAX 408.428.9600

2 International Organization for Standardization, ISO Central Secretariat, 1, rue de Varembé, Case postale 56, CH-1211 Geneva 20, Switzerland.

Telephone: 41.22.749.01.11; Fax: 41.22.733.34.30, Website: /www.iso.ch

3 Object Management Group, Inc., 250 First Ave. Suite 100, Needham Mass. 02494, Telephone: 781.444.0404; Fax: 781.444.0320, Website:

www.omg.org

SEMI E139-0705 © SEMI 2005 5

5 Terminology

5.1 SEMI Compilation of Terms

5.1.1 Definitions or descriptions of many of the terms used in this specification can be found in the SEMI

Compilation of Terms, available on the SEMI web site,

http://www.semi.org/; and in the OMG UML specification.

For terms related to object models, the definition from the OMG UML specification has precedence.

5.2 Abbreviations and Acronyms

5.2.1 FICS — Factory Information & Control System

5.2.2 PDE — Process Definition Element

5.2.3 RaP — Recipe and Parameter Management – this specification.

5.2.4 UML — Unified Modeling Language

5.3 Definitions

5.3.1 Checksum — a single unique value calculated from a sequence of data (a file, a string, etc.) that uniquely

identifies that data. It is sometimes called a “digital fingerprint” or a “message digest”. No two (different)

sequences of data are likely to have the same checksum. Therefore, a checksum can be used to check data integrity.

A typical method is to 1) calculate the checksum for a data sequence; 2) deliver that data sequence and its checksum

value to a separate entity; 3) the receiving entity recalculates the checksum value and compares it with the original

from the sender. If the checksums are the same, the receiver is assured that the data has not been modified or

corrupted.

5.3.2 Factory Information and Control System (FICS) — the software system that controls the operation of the

factory and its equipment. It may include such components commonly referred to as the MES, Station Controllers,

Recipe Managers, etc.

5.3.3 Module Parameter — settings that affect processing on an equipment module (typically a Process Module).

For a Process Module, the Module Parameters might represent temperatures, pressures, flow rates, etc. An

equipment recipe typically manipulates Module Parameters to accomplish its purpose.

5.3.4 PDE (Process Definition Element) — an executable specification of an activity or process on an equipment.

The recipe for a particular equipment activity may consist of multiple PDEs. A PDE is the smallest process

definition unit that can be individually managed with FICS participation or knowledge. Each PDE includes a

PDEheader and a PDEbody.

5.3.5 PDEbody — the executable portion of a Process Definition Element. The PDEbody is typically contained

within the PDE construct. In some cases, a PDEbody may exist as a separate entity, but it is always exclusively

related to its PDE.

5.3.6 PDEeditor — a software system that provides the ability to create, delete, and modify a PDE. A PDEeditor

may exist as a subsystem of an equipment or as a standalone system provided either by the manufacturer of the

equipment or a third party.

5.3.7

PDEheader — the descriptive portion of a Process Definition Element. The PDEheader is a collection of

information related to a PDEbody. This information is sufficient to manage and utilize the PDE without accessing

its PDEbody.

5.3.8 uuid — universally unique identifier. This 128-bit field (often represented as a 36-character string) is

calculated according to the standard ISO/IEC 11578:1996 – Remote Procedure Call (RPC). The field is guaranteed

to be unique over all space and time. The uniqueness holds even though the uuids are created independently by

separate entities.

5.3.9 Variable Parameter — a formally defined variable (setting) defined in the body of a recipe, permitting the

actual value to be supplied externally.

SEMI E139-0705 © SEMI 2005 6

6 Conventions

6.1 The following conventions are used in this document:

 To highlight terms specific to RaP, a term appears in italics within the specification. Italicized terms include

class names, attributes, and services. Service names also end in (), for example “getPDE()”.

 To prevent the definition of numerous message parameters named "XxxList," this document adopts the

convention of referring to the list as "list of Xxx". In this case, the definition and data type of the parameter will

be given (not the type of the list). The term "list" indicates a collection (or set) of zero or more items of the

same data type.

6.2 Object Modeling

6.2.1 Unified Modeling Language (UML)

6.2.1.1 This specification uses UML notation for all class diagrams and for any object diagrams provided as

examples. No other types of object modeling diagrams are used in this specification.

6.2.2 Class Diagrams

6.2.2.1 UML class diagrams have clearly defined meaning and are a part of this specification. Detail contained in

these diagrams is not necessarily repeated in the text.

6.2.3 Name of a Class

6.2.3.1 The text capitalizes class names. Class attributes and services begin with lowercase letters.

6.2.4 Abstract and Concrete Classes

6.2.4.1 Each class is specified as Abstract or Concrete. Abstract classes are not directly implemented (that is, there

are no instances). All classes defined as concrete may be directly implemented. In UML class diagrams, abstract

class names are shown in italics.

6.2.5 Class Attribute Definition

6.2.5.1 The attributes of a class are defined in table format as illustrated by Table 1 below. Note that the “+” sign in

front of attributes in UML class diagrams indicates “public” attributes. All attributes defined in this specification

are public, therefore the “+” sign is omitted.

Table 1 Attribute Table Format

Attribute Name Definition Access Reqd Form

RO or

Y or

See list below.

6.2.5.1.1 Access — Attributes may be settable (ReadWrite or RW) or not settable (ReadOnly or RO) through an

interface to the service provider.

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

6.2.5.1.3 Form — Defines the data type of the attribute. Data types in this specification are high-level definitions

and should be mapped to the data types of a specific technology as appropriate. In this specification, these data

types are also used for the parameters of message services.

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

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

4 The attribute table is a common format used by multiple standards. Note that all attributes defined by RaP are ReadOnly (RO).