semi合集-English.pdf - 第1861页

SEMI E53-0704 © SEMI 1996, 2004 1 SEMI E53-0704 EVENT REPORTING This standard was technically approved by the Globa l Informat ion & Control Committee and is the direct responsibility of the Japanese Inform ation &am…

SEMI E42.1-0704 © SEMI 1996, 2004 8

NOTICE: SEMI makes no warranties or

representations as to the suitability of the standards set

forth herein for any particular application. The

determination of the suitability of the standard 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 mentioned herein. These

standards are subject to change without notice.

The user’s attention is called to the possibility that

compliance with this standard may require use of

copyrighted material or of an invention covered by

patent rights. By publication of this standard, SEMI

takes no position respecting the validity of any patent

rights or copyrights asserted in connection with any

item mentioned in this standard. Users of this standard

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.

International), 3081 Zanker Road, San Jose, CA 95134. Reproduction o

the contents in whole or in part is forbidden without express written

consent of SEMI.

SEMI E53-0704 © SEMI 1996, 2004 1

SEMI E53-0704

EVENT REPORTING

This standard was technically approved by the Global Information & Control Committee and is the direct

responsibility of the Japanese Information & Control Committee. Current edition approved by the Japanese

Regional Standards Committee on April 30, 2004. Initially available at www.semi.org June 2004; to be

published July 2004. Originally published December 1996.

1 Purpose

1.1 Access to process data in equipment is crucial for

effective process monitoring and control in a

semiconductor manufacturing facility. This standard

addresses the communication needs of semiconductor

equipment and other factory objects, such as cell

controllers or recipe servers, with respect to the timely

collection and reporting of such data.

1.2 The purpose of this standard is to provide a general

purpose set of event reporting services that may be

offered by equipment suppliers. This document may be

referenced, in whole or in part, by other standards

addressing higher level application domains.

1.3 The communications services defined here will

enable standards based inter-operability of independent

systems. They shall allow application software to be

developed which can assume the existence of these

services and allow software products to be developed

which offer them.

2 Scope

2.1 This standard is applicable to any stand-alone

equipment, cluster module, cluster tool, or cell of

automation in a factory. As such it addresses event

reporting at all levels in the factory and equipment

control hierarchy.

2.2 This standard requires significant communication

and computational resources and is therefore not

applicable at or below the level of I/O distribution (e.g.,

sensor bus) within the equipment.

2.3 This standard covers the reporting of data

periodically and/or in response to events. Reports may

also be requested on demand.

2.4 This standard presents a solution from the concepts

and behavior down to the messaging services. It does

not define the messaging protocol.

2.5 A messaging service includes the identification that

a message shall be exchanged and definition of the data

which is contained in that message. It does not include

information on the structure of the message, how the

data is represented within the message, or how the

message is exchanged. This additional information is

contained with the message protocol. The defined

services may be applied to multiple protocols.

Information on the mapping of these services to special

protocols (e.g., SECS II) are added as adjunct

standards.

2.6 The services assume a communications

environment in which a reliable connection has been

established between the user and the provider of the

services. Establishing, maintaining, and releasing a

connection is beyond the scope of this standard.

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 Referenced Documents

3.1 SEMI Standards

SEMI E5 — SEMI Equipment Communications

Standard 2 Message Content (SECS-II)

SEMI E30 — Generic Model for Communications and

Control of SEMI Equipment (GEM)

SEMI E38 — Cluster Tool Module Communications

(CTMC)

SEMI E39 — Object Services Standard: Concepts,

Behavior, and Services

SEMI E40 — Standard for Processing Management

NOTICE: Unless otherwise indicated, all documents

cited shall be the latest published versions.

4 Terminology

4.1 The following definitions are arranged in

alphabetical order. Some terms are defined using terms

defined elsewhere within this section. Other terms may

be defined within SEMI’s Compilation of Terms.

4.1.1 attribute — a data item associated with an object.

An attribute may be referenced by zero or more data

reports.

4.1.2 behavior — the manner in which something

functions; how an object acts and reacts, in terms of its

state changes and message passing.

SEMI E53-0704 © SEMI 1996, 2004 2

4.1.3 collection event — an event that may be used to

initiate the collection and reporting of data. A collection

event may trigger an event report. A collection event

may also start or stop one or more trace reports.

4.1.4 data report — a data report is a list of attribute

names for a single object. Data reports may be pre-

defined by a factory object or defined dynamically by

the service user.

4.1.5 default object — the object assumed when no

object specifier is supplied.

4.1.6 event — represents the occurrence of a change in

the condition of a system (e.g., lot complete,

temperature over range).

4.1.7 event report — a class of objects that has

information related to an event and can be linked to

user defined data reports and can send messages

containing this information to a service user.

4.1.8 factory object — any identifiable object within

the factory information and control architecture.

Examples include equipment, a cluster process module,

a cell controller, a recipe namespace server.

4.1.9 object — defined in the Object Services (SEMI

E39).

4.1.10 object specifier — defined in the Object

Services (SEMI E39).

4.1.11 services — a set of closely related messages.

4.1.12 service provider — a service provider is an

application responsible for providing services to service

users.

NOTE 1: There may be one or more service users

concurrently accessing a single service provider. It is the

responsibility of the service provider to provide its services

transparently to each service user.

4.1.13 service user — a service user is any application

that uses the services.

4.1.14 trace report — a class of objects which provides

to a service user a means for collecting periodic

readings of selected attributes of a system.

4.2 Data Types

4.2.1 form — type of data: float, positive integer,

unsigned integer, integer, enumerated, boolean, text,

formatted text, structure, list, ordered list.

4.2.2 float — a number represented by a mantissa and

an exponent. It is used to represent numeric data which

is continuous in value.

4.2.3 positive integer — May take the value of any

positive whole number. Messaging protocol may

impose a limit on the range of possible values.

4.2.4 unsigned integer — May take the value of any

positive integer or zero. Messaging protocol may

impose a limit on the range of possible values.

4.2.5 integer — May take the value of any negative or

unsigned number. Messaging protocol may impose a

limit on the range of possible values.

4.2.6 enumerated — May take on one of a limited set

of possible values. These values may be given logical

names, but they may be represented by any single-item

data type.

4.2.7 boolean — May take on one of two possible

values; TRUE or FALSE.

4.2.8 Text — A text string. Messaging protocol may

impose restrictions, such as length or ASCII

representation.

4.2.9 formatted text — a text string with an imposed

format. This could be by position, by use of special

characters, or both.

4.2.10 structure — a complex structure consisting of a

specific set of items, of possibly mixed data types, in a

specific arrangement.

4.2.11 list — set of one or more items that are all of the

same form (one of the above forms).

4.2.12 ordered list — s list for which the order in

which the items appear is significant.

5 Conventions

5.1 Harel State Model — This document uses the Harel

State Chart notation to describe the dynamic behavior

of the objects defined. 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.

5.1.1 Transition tables are provided in conjunction with

the state diagrams to explicitly describe the nature of

each state transition. A transition contains columns for

transition #, current state, trigger, new state, action(s).

The “trigger” (column 3) for the transition occurs while

in the “current” state. The “actions” (column 5) include

a combination of; 1) actions taken upon exit of the

current state, 2) actions taken upon entry of the new

state, and 3) actions taken which are most closely

associated with the transition. No differentiation is

made.

5.2 OMT Object Information Model — The object

models are presented using the Object Modeling

Technique developed by Rumbaugh, James, et al, in

“Object-Oriented Modeling and Design,” Prentice Hall,