semi合集-English.pdf - 第1808页
SEMI E42-0704 © SEMI 1995, 2004 77 "the best ve rsion" to be deter mined by the namespace at a later stage. The verify operation is invoked explicitly with the RMEVerify se rvice. It may also be pe rformed as p…
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
of
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.
SEMI E42-0704 © SEMI 1995, 2004 78
The delete recipe operation is invoked with the
RMEDelete service. A request to delete a currently
selected recipe shall be denied.
11.2.7 Recipe Selection — Recipe selection is the
process of locating, validating, and preparing a recipe
for execution within the execution area. Recipe
selection is a required operation of the recipe executor
that allows specification of initial (default) values of
any variable parameters defined by the recipe. Initial
parameter values specified at this time shall override
the corresponding values contained in the Exec-
LinkParam attribute.
It shall be possible to explicitly specify a recipe for
execution. It may also be possible to implicitly select a
recipe, including initial variable parameter values,
through other operations, such as within a higher-order
"process job". Services for implicit methods and for
starting execution itself are beyond the scope of RMS.
If the recipe class is omitted when specifying a recipe
for selection, then the class "/PROCESS/" shall be
assumed.
The request for recipe selection specifies one or more
recipes to be selected. If a recipe cannot be located in
the recipe executor's recipe storage area, then the recipe
executor may optionally attempt to locate and retrieve it
from the originating namespace specified.
Only a linked recipe (with the Linked
attribute set to
TRUE) may be specified by the service user. An
attempt to select an unlinked recipe shall be denied.
Subrecipes that are part of a linked recipe set are
required only to be verified but not linked.
The selection process completes abnormally whenever
an error is detected, including the failure to locate a
specified recipe or to successfully store it, invalid
parameter settings, an attempt to select an unverified
recipe, and other validation errors.
The select recipe operation is invoked with the
RMESelect service.
11.2.7.1 Multiple Selection — Executing agents that
support subclasses of the PROCESS class shall provide
at least one of two methods for the selection of multiple
recipes: (1) they may either allow, or require, that a
request for recipe selection explicitly specify a recipe
from each of certain subclasses, and/or (2) they may
either allow, or require, specification of required
subclasses within a linked set of multi-part recipes.
Such additional permissions and restrictions shall be
included in the recipe management documentation.
For executing agents that support multi-part recipes
(such as described in method 2 above), the recipe
executor is responsible for validating, as a set, the main
recipe and all its subrecipes listed in the LinkList
attribute of the main recipe as a condition of execution.
If the namespace is specified as "Default", the default
namespace is used. The name of this namespace is the
value in the recipe executor attribute DefaultName-
space (see Section 6.4 and 6.7).
All recipes in the linked recipe set are considered to be
selected if the select operation is successful.
11.2.7.2 Validation — Validation consists of type and
range-checking of recipe settings and parameters, and
of confirmation that the recipe is valid for the current
hardware configuration. Validation shall occur as part
of the process of selection. For recipe executors that
require several different classes of recipe, validation
may depend on the recipes that are selected as a set.
For example, a diffusion furnace may have a class of
recipe that is used for the current gas configuration to
map gases to valves. The furnace's normal process
recipe that uses names of gases can only be validated in
combination with the gas configuration table selected at
the same time.
11.2.7.3 Delegation — If delegated recipes are
specified in LinkList
, it is the responsibility of the
recipe executor to ensure that the designated recipe is
accessible to the recipe executor of the component
agent at the time it is selected. Otherwise, the select
request shall be denied.
11.2.7.4 Variable Parameters — For recipes with
variable parameters, new initial values for some or all
of its parameters may be specified as part of the
selection as a parameter name and parameter initial
value pair. Parameter values specified as part of the
selection take precedence over those initial values
defined in the ExecLinkParam
attribute. However,
parameter restrictions may not be changed when
selecting a recipe.
All parameter values that are set either prior to, or
during
12
, the execution of a recipe shall satisfy the
conditions of the parameter restriction. If a parameter
restriction is given in the ExecLinkParam attribute,
then that restriction is used for all occurrences of the
parameter.
11.2.7.5 Message Scenarios — There are two possible
message flows between the recipe executor and the
service user for the select service.
If the recipe executor is able to locate the recipes in its
local storage, to validate them as a set, and to ready
12 RMS neither defines, nor prohibits, methods for changing
parameter values during the execution process.