semi合集-English.pdf - 第1741页

SEMI E42-0704 © SEMI 1995, 2004 10 1.5.4 Service Me ssage Representation Service Resource Definition A service definition table defines the specific set of messages for a gi ven service resource , as show n in the follow…

SEMI E42-0704 © SEMI 1995, 2004 9

validate — The action of checking recipe contents to

ensure that parameter type

and range are valid for the

equipment configuration prior to execution. [Note that

validation and verification are used in different ways.]

variable parameter — A formally defined variable

(setting) defined in the body of a recipe permitting the

actual value to be supplied externally.

verify — The operation of reading a recipe's contents to

ensure that it is syntactically correct and identifying

elements that must be made public.

version — Part of a recipe's identifier that is used to

show its heritage.

1.5 Conventions — The following conventions are

used in this document:

• To highlight terms specific to RMS (excluding

terms defined in Sections 1.4.1 through 1.4.3 that

are common to multiple standards), a defined term

appears in boldface wherever it first appears and

wherever it is defined. This alerts the reader to

those terms with specific meanings. Except for

terms that are very common, such as recipe, host,

and equipment, defined terms otherwise are in

italics wherever they appear.

• Terms related to objects and object services are in

conformance with SEMI E39 (Object Services

Standard: Concepts, Behavior, and Services). A

brief discussion of objects is provided in the

Appendix of that document.

• Attribute names are underlined

• Attributes called "names" in RMS are generally

intended to be used for the ObjID

attribute of a

standardized object.

• 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 of the parameter

Xxx will be given, not of the list. The term "list"

indicates a collection (or set) of zero or more items

of the same data type.

For attributes that are lists, this convention is not

followed, as the entire attribute, as a list, must be

assigned a specific name.

1.5.1 Text String Restrictions — Text strings used in

attribute names, attribute values, or message

parameters, are subject to the restrictions defined by

OSS: Text in ASCII is restricted to the characters

between 20

and 7D

, excluding the question mark "?"

(3F

), the asterisk "*" (2A

), and the tilde "~" (7E

Text strings used as, or within, the object identifier

ObjID

are additionally restricted to exclude the "greater

than" symbol ">" (2E

) and the colon character ":"

(3A

) to conform with OSS requirements.

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

This document also adopts the extension of Harel

notation to show the deletion of an object as used by

Rumbaugh, et al. (see Section 1.5.2.1).

1.5.3 Objects — Standardized objects defined by RMS

conform to the requirements of SEMI E39 (Object

Services Standard: Concepts, Behavior, and Services).

RMS adopts the convention of showing standardized

objects as drawn with a heavy line in object models.

Non-standardized objects are used to illustrate concepts

and relationships but are not formally defined and

cannot be accessed through Object Services. A list of

standardized objects defined by RMS is included in

Related Information 1.

1.5.3.1 OMT Object Information Model — The object

models are presented using the Object Modeling

Technique, developed by Rumbaugh et al., in Object-

Oriented Modeling and Design, Prentice-Hall,

Englewood Cliffs, NJ, 1991. Overviews of this notation

are provided in an appendix of SEMI E39 (Object

Services Standard: Concepts, Behavior, and Services).

1.5.3.2 Object Attribute Representation — The object

information models for standardized objects will be

supported by an attribute definition table with the

following column headings:

Attribute

Name

Definition Access Rqmt Form

The formal

text name of

the attribute.

Description of the

information

contained.

RO or

Y or N (see

below)

The Access column uses RO (Read Only) or RW (Read

and Write) to indicate the access that users of the

service have to the attribute.

A 'Y' or 'N' in the Requirement (Rqmt) column

indicates if this attribute must be supported in order to

meet fundamental compliance for the service.

The Form column is used to indicate the format of the

attribute. (See Section 1.4 for definitions.)

SEMI E42-0704 © SEMI 1995, 2004 10

1.5.4 Service Message Representation

Service Resource Definition

A service definition table defines the specific set of

messages for a given service resource, as shown in the

following table:

Message Service Name Type Description

Message name N or R The intent of the service.

Type can be either N = Notification or R = Request.

Notification type messages are initiated by the service

provider, and the provider does not expect to get a

response from the user.

Request messages are initiated by a service user.

Request messages ask for data or an activity from the

provider. Request messages expect a specific response

message (no presumption on the message content).

Service Parameter Dictionary

A service parameter dictionary table defines the

parameters for one or more services, as shown in the

following table:

Parameter Form Description

Parameter X Data type A parameter called X is B in

A row is provided in the table for each parameter of the

service. The first column contains the name of the

parameter. This is followed by columns describing the

form and contents of the corresponding primitive.

The Form column is used to indicate the type of data

contained in a parameter. (See Section 1.4 for

definitions.)

The Description column in the Service Parameter

Dictionary table describes the meaning of the

parameter, the values it can take on, and any

interrelationships with other parameters.

To prevent the definition of numerous parameters

named "XxxList", this document adopts the convention

of referring to the list as "(List of)Xxx". In this case, the

definition of the variable Xxx will be given, not of the

list. The term "list" indicates a collection (or set) of

zero or more items of the same data type. Where a list

is used in both the request and the response, the list

order in the request is retained in the response. A list

must contain at least one element, unless zero elements

are specifically allowed.

Service Message Definition

A service message definition table defines the

parameters used in a service, as shown in the following

table:

Parameter Req/Ind Rsp/Conf Description

Parameter X (see

below)

(see

below)

A description of the

service.

The columns labeled Req/Ind and Rsp/Conf link the

parameters to the direction of the message. The

message sent by the initiator is called the "Request".

When receiver terms this message the "Indication" or

the "Request", the receiver may then send a

"Response", which the original sender terms the

"Confirmation".

The following codes appear in the Req/Ind and

Rsp/Conf columns and are used in the definition of the

parameters (e.g., how each parameter is used in each

direction):

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

"U" — User-defined parameter.

"-" — The parameter is not used.

"=" — (for Response only) Indicates that the value

of this parameter in the response must match that in

the primary (if defined).

1.6 Requirements — Requirements for recipe

management are varied. For example, there is a

fundamental need to retain information about each

recipe, to provide that information upon request, and to

transfer it with the recipe so that it remains available.

There is a need to classify recipes, to reuse them, and to

share them with multiple installations of equipment.

The need for sharing recipes introduces a new

requirement for safeguarding the relationship between a

recipe's identifier and its contents, to be able to protect

a recipe from unauthorized changes, and to ensure that

the identifier for a recipe that is used by multiple

equipment is in fact the same recipe.

The requirements for managing recipes in a factory are

given in tabular form in Table 1.1, which presents them

according to their functional areas and the specific

issues involved. Table R1-1, in Related Information,

shows the specific concepts defined in RMS to address

each of these requirements.

Table 1.1 Requirements

Functional Areas Issue Requirements

Management of Recipes Identification Uniquely store, identify, and select recipes in a system.

Easy and clear identification of a recipe.

Multiple Access Share recipes among equipment.

Enable synchronized change of shared recipes among equipment.

History and Traceability Capture the history of recipe usage.

Capture the history of recipe changes.

Life Cycle Management Manage approval of recipes for process development and production.

Operations Protection Protect recipes from unexpected changes.

Protect recipes from mistakes in operations.

Portability Create, edit, and change recipes outside the equipment which execute

them.

Reusability Change recipes for a specific piece of equipment.

Use recipes developed on one piece of equipment for other equipment.

Share recipes among the same kind of equipment by adjusting for

individual differences.

Execution Safety Do not execute recipes that are not syntactically correct.

Execute the specified (selected) recipes without errors.

Protect recipes being executed from inadvertent change caused by other

activities.

Flexibility Change a recipe's parameters during or between runs in a systematic

way.

System Operation System Node Operation Dynamically connect and disconnect equipment to/from the

communications network.

Stand-Alone Operation Execute recipes with no communications link.

Create and change recipes with no communications link.

Manage recipes moved between equipment or from off-line storage

through removable media.

Enable smooth integration of stand-alone equipment into on-line factory

systems.