semi合集-English.pdf - 第1807页

SEMI E42-0704 © SEMI 1995, 2004 76 11.1 Object Services Opera tions — A recipe executor shall comply with Obj ect Services Standard specifications for fundamental requirements and with the requirem e nts for Owne r Objec…

SEMI E42-0704 © SEMI 1995, 2004 75

10.4.2 Recorder Operations Table — Table 10.2 lists all the operations defined for distributed recipe namespace

recorder.

Table 10.2 Distributed Recipe Namespace Recorder Operations

Operation Invoked by Description Reqd

add segment record the recorder’s manager A segment specifier is added to the

current list.

delete segment record the recorder’s manager A segment specifier is removed from the

current list.

add change request record the recorder’s manager A currently active change request

record is added for a specified recipe.

delete change request record the recorder’s manager An existing change request record is

removed for a specified recipe.

get change request records any The change request records for one or

more recipes are requested.

10.4.3 Manager Operations Table — Table 10.3 lists all the operations defined for distributed recipe namespace

manager.

Table 10.3 Distributed Recipe Namespace Manager Operations

Operation Invoked by Description Reqd

segment change request an attached segment A segment requests approval for a

specified type of change on a specified

recipe.

segment change complete an attached segment A segment’s notification that an

approved change has been completed,

either normally or abnormally.

segment notification an attached dedicated segment A dedicated segment’s notification that

an agent-specific dataset has been

changed.

get change requests any A request for the list of existing change

requests for a specified recipe.

rebuild distributed namespace an authorized user A manager is requested to rebuild a

distributed recipe namespace using a

specified recorder.

11 Recipe Executor Operations

The operations of the recipe executor defined by RMS are: download and verify, verify, upload, rename, get

available storage, delete, select, deselect, and change notification. In addition, the recipe executor shall provide

object services as described in Section 11.1.

Recipe executor operations may be invoked by an operator or through recipe executor services defined in Section

14. In most cases, service scenarios consist of a single message request from the service user and a corresponding

response from the recipe executor. This case is illustrated in Section 14.1.

Scenarios are shown only for operations that differ from this typical case. For example, some operations may require

more time to complete, such as recipe verification and the select operation that may be performed on more than one

recipe and may require interactions with a recipe namespace to complete. In this case, the initial response to the

message service request may only indicate the intent to perform the operation. The recipe executor informs the

service user of the completion of each individual operation by sending the notification message RMEComplete.

In addition, in restricted circumstances, the recipe executor is required to inform a namespace that a recipe body

originally downloaded from that namespace has been changed.

SEMI E42-0704 © SEMI 1995, 2004 76

11.1 Object Services Operations — A recipe executor

shall comply with Object Services Standard

specifications for fundamental requirements and with

the requirements for Owner Objects. Support for

Filtering is optional.

A recipe executor owns the execution recipes that it

stores, and it is owned by the agent that provides recipe

executor. The owner relationships are used by Object

Services to define a recipe specifier.

The recipe executor shall support operations for Get

Attributes and Set Attributes for its own attributes. It

shall support the operation of Get Attributes for the

execution recipe. (Note that all attributes of the

execution recipe are read-only and may not be set

through the interface. It shall support the Get Type and

Get Attribute Name operations for the object types of

recipe executor and execution recipe.

11.1.1 Execution Recipe Specifier — The object

specifier for an execution recipe includes the object

type and identifier of the recipe executor, followed by

the identifier of the recipe, including its originating

namespace. For example, to specify an execution recipe

"NS-MOM>PROCESS/ABC;5>" that is stored by a

recipe executor named "RE-Etch" owned by "Agent-

:Etch01", the object specifier would be

"Agent:Etch01>RcpExec:RE-Etch>NS-MOM>PROCESS/

ABC;5>".

11.2 Description of Operations — This section

describes the operations of the recipe executor.

11.2.1 Recipe Download and Verify — A recipe is

downloaded when it is transferred (sent) to the recipe

executor. Downloaded recipes that do not have the

Verified

attribute set to TRUE shall be immediately

verified. Otherwise, it is not necessary to re-verify a

recipe. Any verification errors shall be reported to the

initiator of the download operation.

For further discussion of the verification operation, see

Section 11.2.2.

Normally, if the identifier of the recipe (namespace

name, recipe class, recipe name, and version number)

is already assigned to an execution recipe already

existing in storage, the download is refused. However,

the initiator of the download operation may optionally

request a forced overwrite of any such pre-existing

recipe. In this case, if the existing recipe is not currently

selected, the new recipe replaces the older one. A

request to delete or overwrite a currently selected recipe

shall be denied.

The body of a recipe currently being edited shall be

protected from inadvertent change or overwriting by a

recipe with the same identifier that is downloaded

during this time. If the downloaded recipe is accepted

(stored), the equipment shall require the operator either

to save the edited recipe to a new (unused) identifier or

to discard it.

The download and verify recipe operation is invoked

with the RMEDnldVer service.

11.2.2 Recipe Verify — This is a required operation

that verifies a specified execution recipe.

Verification requires reading the recipe's body. For a

source form recipe, the verification operation checks

the contents of the recipe for syntactical correctness. If

supported, the recipe executor may also include one or

more checks for semantic correctness as part of its

verification operation. For recipes in object form,

verification checks the format of the contents to achieve

the same effect.

A verified recipe merely indicates that it is technically

correct and can be executed. It does not indicate that it

can be properly executed for the current hardware

configuration. Checking to ensure a recipe will execute

properly is called validation and shall only be

performed at the time recipes are selected for execution.

A recipe that has syntactical or format errors fails the

verification process. Information concerning errors

shall be reported to the initiator of the verification

process. This information is required for the user to be

able to make appropriate corrections.

Information returned to the namespace manager at the

conclusion of the verification process includes:

• All external references, required for the ExtRef

attribute of the managed recipe,

• All variable parameter definitions, required for the

Parameters

attribute of the managed recipe,

• The estimated or nominal time of the recipe, in

seconds, used for the EstRunTime attribute of the

managed recipe (optional).

These items are not returned if the recipe fails

verification. In this case, the recipe executor shall

provide sufficient information to the user for

identification of the type of error and where within the

body it occurred, for at least the first error encountered.

The external references that are returned shall always

include the name of the recipe referenced, and any

referenced namespace, in the proper form for a recipe

identifier. If the external reference specifies a

namespace other than "Default" (Section 6.4), the

version is required to be fully specified for verification

to be successful. Otherwise, version shall be left exactly

as specified in the body. Omission of version allows

SEMI E42-0704 © SEMI 1995, 2004 77

"the best version" to be determined by the namespace at

a later stage.

The verify operation is invoked explicitly with the

RMEVerify service. It may also be performed as part of

the download and verify operation as discussed in

Section 11.2.1.

11.2.2.1 Derived Object Form Recipes — For

downloaded recipes that are to be stored, the recipe

executor may wish to re-write or compress a source

form recipe into a derived object form recipe (Section

3.2.2.1.2) as part of the verification process. (The

rewritten form may be of any format and is typically

not a form of "machine-executable code".)

Where downloaded recipes are converted to a derived

object form prior to storage, a method of re-converting

to source form is required. Note that the capability to

retain user comments is desirable, but not required,

where this process is adopted.

The new derived object form recipe inherits the

attributes of the source form recipe with the following

exceptions:

• The class or name of the object form shall be

changed in a systematic and documented manner

that both makes clear the object form derivative

and its heritage from the source form original. For

example, the object form may add an extension to

the name of the original recipe.

• The BodyFormat

attribute shall be changed to

reflect the object form.

• The attributes ExecLength

, ExecChgTime,

BodyLength

, and EditTime shall be updated.

If the attribute ExecChgCtrl

requires the originating

namespace to be notified of changes, then this request

applies to the creation of the derived object form recipe,

and the ChangedBody attribute is set to TRUE until the

recipe has been uploaded successfully by the

namespace manager.

The source form recipe from which the derived object

form was obtained should not be deleted automatically.

11.2.2.2 Verification ID — The attribute

VerificationID

is used for derived object form recipes

and is provided for the recipe executor identification

code. This is a text string containing a unique and

persistent "signature" or identifier for the recipe

executor. This is used to detect derived object form

recipes that were derived by earlier software versions of

the recipe executor, or by versions used by other

agents, that may have obtained different results.

The identifier of the source form recipe of the derived

object form recipe is stored in the attribute SrcRcpID

the derived object form recipe.

11.2.3 Recipe Upload — Recipe upload is the

operation that returns an execution recipe from the

recipe executor's storage to the service user. It is

required for recipe executors that are able to originate

or modify recipes. Recipe upload allows recipes to be

managed in a recipe namespace.

The upload recipe operation is invoked with the

RMEUpload service.

11.2.4 Recipe Rename — The recipe rename

operation causes a recipe to be assigned a new

identifier. If the new identifier is already in use by a

pre-existing execution recipe, or if the recipe to be

renamed is currently selected, the request shall be

denied. This is a required operation.

This service is provided to maintain synchronization

between execution recipes and the managed recipes

within an originating namespace.

The rename recipe operation is invoked by the message

service RMERename.

11.2.5 Get Available Storage — The get available

storage operation is used to determine the size of the

remaining recipe storage capacity, in bytes. The value

returned shall exclude any overhead requirements for

storage of one execution recipe. That is, it shall be

assumed that sufficient storage exists for a single recipe

with a combined attribute length and body length less

than or equal to the returned value. This is a required

operation.

The get available storage operation is invoked by the

message service RMESpaceInquire.

11.2.6 Recipe Delete — The recipe delete operation

removes one or more recipes from the execution recipe

storage. Any reusable (rewritable) storage used by a

deleted recipe shall be made available for other recipes,

and the deleted recipe shall be unavailable for all

subsequent operations. This is useful to release storage

for new recipes. This is a required operation.

Recipes stored in non-reusable storage that cannot be

physically deleted shall be made unavailable for

subsequent selection.

If the recipe executor does not have execution recipe

storage (that is, if its sole storage is the recipe

execution area), then the delete operation shall

completely remove the specified recipes from the

recipe execution area.