semi合集-English.pdf - 第1856页

SEMI E42.1-0704 © SEMI 1996, 2004 4 Parameter Name SECS-II Data Item AttachToken OBJTOKEN RMChgType RMCHGTYPE RMManagerSpec OBJSPEC RMPermit RMGRNT RMRecorderSpec OBJSPEC (S15,F 43) and RMRECSPEC otherwise RMRequestor RM…

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

Parameter Name SECS-II Data Item

AttrData RCPDESCLTH

AttrName ATTRID

BodyData RCPBODY

BodyDescLength RCPDESCLTH

BodyDescName RCPDESCNM = “BodyDesc”

BodyDescTimestamp RCPDESCTIME

BodySectionName RCPSECNM = “Body”

ErrorCode ERRCODE

ErrorText ERRTEXT

GenAttrSectionName RCPSECNM = “Generic”

GenDescLength RCPDESCLTH

GenDescTimestamp RCPDESCTIME

LinkID LINKID

NSAck RMACK

RcpClass RCPCLASS

RcpName RCPNAME

RcpVersion RCPVERS

RMAction RCPCMD

RMAgent AGENT

RMChangeStatus RMCHGSTAT

RMDestRecID RCPNEWID

RMNewNS RMNEWNS

RMNSSpec RMNSSPEC

RMOpID OPID

RMParamName RCPPARNM

RMParamRule RCPPARRULE

RMParamSetting RCPPARVAL

RMRcpID RCPID

RMRcpSpec RCPSPEC

RMRcpStat RCPSTAT

RMSectionsCode RCPSECCODE

RMSpace RMSPACE

RcpDerivedID RCPID

REAck RMACK

REAttrDescLength RCPDESCLTH

REAttrDescName RCPDESCNM = “REAttrDesc”

REAttrDescTimestamp RCPDESCTIME

REAtrSectionName RCPSECNM = “Attribute”

REChangeStatus CHGCODE

REDerivedID RCPID

REDestRcpID RCPNEWID

REOpID OPID

REWOCode REOWCODE

REParamName PARAMNAME

REParamSetting PARAMVALUE

RERcpID RCPID

RERcpSpec RCPSPEC

RESpace RMSPACE

RESpec RESPEC

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

Parameter Name SECS-II Data Item

AttachToken OBJTOKEN

RMChgType RMCHGTYPE

RMManagerSpec OBJSPEC

RMPermit RMGRNT

RMRecorderSpec OBJSPEC (S15,F43) and RMRECSPEC otherwise

RMRequestor RMREQUESTOR

RMSegSpec RMSEGSPEC

RMTimestamp TIMESTAMP

TargetSpec TARGETSPEC

6.2 There are also several data items that are used in the SECS-II messages which do not map to specific services

parameters. Services with the same set of parameters are mapped to the same SECS-II message by adding an

additional data item to differentiate between the services. In addition, SECS-II restrictions require multi-block

primary messages to be preceded by a multi-block inquire/grant transaction defined within the same stream. For

RMS messages, this requirement is satisfied with the S15,F1 and F2 messages. Data items defined for these two

messages have no counterpart in RMS service parameters.

6.3 Table 3 contains the SECS-II data items that have no corresponding RMS service parameter:

Table 3 Additional Data Item Requirements Table

Function SECS-II Data Item

Used to satisfy SECS-II conventions for linking a multi-block inquiry with a subsequent multi-

block message.

DATAID

Used for the name of any non-identifier recipe attribute. RCPATTRID

Used for the value of any non-identifier recipe attribute. RCPATTRDATA

Used by S15,F19 to differentiate between RMNCopy and RMNRename services. RCPRENAME

Used to satisfy SECS-II multi-block requirements. RMGRNT

Used by S15,F3 to differentiate between RMNCreateNS and RMNDeleteNS services.

Used by S15,F39 to differentiate between RMDRAddSegRecord and RMDRDelSegRecord.

Used by S15,F41 to differentiate between RMDRAddChgRecord and RMDRDelChgRecord.

RMNSCMD

Used to satisfy SECS-II multi-block requirements. Neither required nor specified by RMS. RMDATASIZE

Used by S15,F13 to differentiate between RMNCreate and RMNUpdate services. RCPUPDT

Used by S15,F35 to differentiate between RMEDelete and RMEDeselect services. RCPDEL

Used by S15,Fy to differentiate between A and B services. RCPDEL

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.

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

RELATED INFORMATION 1

NOTE: This related information is not an official part of SEMI E42.1 and is not intended to modify or supercede the

official standard. Publication was authorized by full letter ballot procedures. Determination of the suitability of the

material is solely the responsibility of the user.

R1-1 RMS-Compliant Equipment with a Stream 7 Host

Semiconductor manufacturers with legacy systems, capable of communicating using Stream 7 messages only, may

still take advantage of many of the Recipe Management concepts when used with equipment that is Recipe

Management-compliant. This section contains guidelines and examples for maintaining recipe attributes within the

body of a Stream 7 process program.

R1-1.1 Recipe Identifier — Both the process program identifier PPID and the object identifier, including the recipe

identifier, have a maximum length of 80 characters. Recipe class, name, and version number may be encoded into

the data item PPID using the format required for the recipe identifier.

“/CLASS

/CLASS

/.../CLASS

/NAME;VERSION”

It is recommended that recipe class names be unique, allowing use of the form

“/CLASS/NAME;VERSION”

to ensure the length conforms to the maximum allowed in SECS-II.

R1-1.2 Recipe Sections — All sections of the recipe are transferred together as the data item PPBODY. This allows

all non-default values of recipe attributes to be preserved when a recipe is uploaded to the host and later downloaded

back to equipment.

There are two potential methods for formatting PPBODY. If the recipe body is a text file, it is recommended that all

attribute values are translated into text, including numeric and boolean values, with boolean values represented by

the strings “.T.” or “.F.”. The second recommended method, applicable to both source and object forms, uses the

structure of one of the SECS-II messages containing the managed recipe, as illustrated in Figure 1, or of an

execution recipe. A cluster tool supporting shared namespaces, for example, might require multiple agent-specific

data sets, while single-process equipment types would not.

R1-1.2.1 Structuring PPBODY Using Text — For purposes of transfer, recipes are regarded as composed of

sections: The generic section, the body section, and zero or more agent-specific data-set sections (RMS, Section

12.1). This convention should also be maintained within PPBODY. The SECS-II messages used to transfer recipes

(Stream 15, Functions 15 and 18) transfer the data-set sections last, because they are variable in number and are not

always present. However, in a text format within PPBODY, it is generally easier to put all attributes before the body.

Since RMS uses the end-of-line character for source form recipes, this convention is recommended to separate the

logical components of the sections containing attributes as well. A few reserved keywords are sufficient as tags to

identify significant components: SECTION, ATTRIBUTE, LIST, PARAMNAME, PARAMSETTING, and

PARAMRULE are recommended for consistency. Keywords are in uppercase for visual impact and are not

delimited except for use of whitespace and the line-feed character (0A

) used as the end-of-line (eol) character.

Whitespace is used to separate fields within a line. The symbol  is used here to represent whitespace, which is used

both as a delimiter to separate fields within a line and also for optional visual effect.

Each section begins with a section declaration of the form

SECTION”text”(eol)

where text is a section name, one of “Generic”, “ASDS”, “Body”. Two sections are separated with two eol

characters together. The eol convention within the body section, however, must conform to the recipe language

specifications provided by the equipment manufacturer.

Each attribute begins with

ATTRIBUTEAttributeName