semi合集-English.pdf - 第1780页
SEMI E42-0704 © SEMI 1995, 2004 49 in the main recipe's attributes. Linking resolves all identifiers ex plicitly for recipes that are within th e namespace . unlink — At times it may be desirable to undo the link op…
SEMI E42-0704 © SEMI 1995, 2004 48
Agents interact with one another collaboratively and/or
hierarchically, through the service resources that they
provide, to perform work in the factory.
7.2 RMS Resources — The service resources defined
by RMS are the recipe namespace resource and the
recipe execution resource.
A recipe namespace resource consists of the set of
message services defined in Section 12, corresponding
to the namespace operations defined in Sections 8 and
9. All services required for operations designated as
required are fundamental and shall be provided for an
RMS-compliant recipe namespace resource.
A recipe execution resource consists of the set of
messages defined in Section 14 corresponding to the
recipe executor operations defined in Section 11. All
services required for operations designated as required
are fundamental and shall be provided for an RMS-
compliant recipe execution resource.
7.3 Agent Attributes — Table 7.1 defines the public
attributes of agents that are required for recipe
management.
Table 7.1 Agent Attribute Definition
Attribute
Name
Definition
Access
Reqt
Form
ObjType Agent object
type.
RO Y Text:
“Agent”
ObjID The agent's
name, assigned
by an
authorized
user.
RO Y Text.
8 Recipe Management Operations
There are two important kinds of operations involving
recipes within a namespace. Those that change a
recipe's attributes or body are called recipe
management operations. Those that affect the set of
recipe identifiers within a namespace are part of recipe
namespace management operations. A few operations
qualify as both recipe management and namespace
management and are discussed in their different aspects
under both topics.
A third type of operation is informational only and
requires reading but not changing recipe attributes.
Operations of this type that require knowledge of the
attributes of the namespace or of more than one recipe
are discussed in Section 9.
This section describes recipe management operations.
Requests for recipe operations are always directed to
the namespace where the recipe is stored. Recipe
management operations are delegated by the namespace
manager to the namespace segment, which is
considered as the recipe manager. This is invisible for
a centralized namespace and explicit for a distributed
recipe namespace.
Operations may be invoked by the operator or through
namespace services defined in Section 12. In many
cases, service scenarios consist of a single message
request from the service user and a corresponding
response from the namespace manager. This case is
illustrated in Section 12.2, Figure 12.1. Operations
requiring additional messages are discussed in Section
8.2.
The service user is responsible for proper authorization
of the user prior to requesting an operation that is
restricted to authorized users
through RMS services.
8.1 Recipe Lifecycle — A typical production recipe
goes through various stages in its development within a
namespace. These stages are shown below in a typical
order through their associated operations. The attributes
concerning the body are provided by the initiator of the
operation.
create — The create operation enters a recipe body
into the namespace.
Editing is expected, but not required, to be performed
outside the namespace. Where provided by the
manager, the same requirements concerning creating or
updating a recipe are to be followed.
update — A recipe is updated when a body (typically,
a modification of the original body) is entered into the
namespace to replace the body of an existing recipe that
is not write-protected. The attributes concerning the
body are provided by the initiator of the operation.
verify — The verify operation is used to build a recipe.
Checks for semantic correctness may also be performed
at this time but are not required. The recipe body is read
and checked for syntactical correctness, and all external
references and variable parameter definitions are
collected. The verification operation may be delegated
to a recipe executor, which returns the required
information.
write-protect — At some point during its development,
an authorized user needs to be able to prevent the
accidental deletion or modification of a recipe and
requests to have it be write-protected. A write-
protected (read-only) recipe may not be updated,
renamed, deleted, unlinked, or relinked.
link — The link operation is used to signify that the
recipe is ready for execution. If the recipe has external
references, linking also builds a linked recipe set by
collecting the external references and variable
parameter definitions and saving them for quick access
SEMI E42-0704 © SEMI 1995, 2004 49
in the main recipe's attributes. Linking resolves all
identifiers explicitly for recipes that are within the
namespace.
unlink — At times it may be desirable to undo the link
operation. The unlink operation clears those attributes
set by the last link operation. A write-protected recipe
may not be unlinked.
approve — The factory uses the recipe's approval level
to indicate the level of its authorization. For example,
approval levels of 1, 2, and 3 may indicate “write-
protected,” “authorized for engineering,” and
“authorized for production,” respectively.
modify variable parameters — The variable
parameter definitions of a linked recipe may be
adjusted for a specific executing agent to achieve the
desired result. For example, a generic parameter for
time may be incremented repeatedly for a specific
furnace until it goes out of range, which indicates that it
needs to be cleaned. If the recipe did not previously
have an agent-specific dataset for this agent, this
operation causes one to be created.
certify — An authorized user (typically by the process
engineer who developed the recipe) assigns it a
certification-level to indicate that it achieves the
desired result on a specific executing agent. The factory
may require certain certification levels for production.
de-certify — the certification level of the recipe is reset
to zero.
unprotect — Before a recipe can be updated, deleted,
renamed, re-linked, or unlinked, the recipe must be
unprotected.
delete — Deleting a recipe causes it to be removed
from the namespace.
8.2 Description of Operations — Operations that
require additional messages are of two types:
operations that may be performed on more than one
recipe (such as certify recipe) and operations that may
require interactions with a recipe executor to complete
(verify recipe). The scenario for verify recipe is shown
in Section 9.4.7.
The remaining operations that require additional
messages are invoked with the namespace service
RMNAction, where multiple recipes are specified for
the operation. Operations such as these may require
more time to complete. The initial response to the
message service request only indicates the intent to
perform the operation. In this case, the scenario is
illustrated by Figure 8.1 and Figure 12.2, Section 12.2.
The namespace manager performs the operation for
each recipe, in the order specified, and upon the
completion of each operation, sends the notification
message RMNComplete with the results for that
operation. (See Sections 12.15 and 12.17 for additional
details.)
Figure 8.1
Message Flow with Completion Notification
Recipe management operations are categorized into
three types: recipe origination, recipe building, and
recipe authorization.
Recipe origination includes those operations that
create or modify an entire recipe. Recipe building
includes the verification, link, unlink, and modify
variable parameter operations. Recipe authorization
includes the write-protect, unprotect, approve, and
certify operations.
Except for those operations that only provide
information, recipe management operations change the
state of the recipe. Section 8.3 contains the complete
state model, and a table of transitions is given in Table
3.1. Substates of this model are provided for illustration
in sections defining the operations that affect these
substates.
8.2.1 General Requirements — The generic length and
timestamp attributes AttrLength
and AttrChgTime shall
be updated whenever any other generic attribute
changes value.
An agent-specific dataset for a specific agent exists
only when a non-required attribute is given a non-
default value, such as whenever a recipe is certified for
a given agent. If the non-required attributes are all
cleared, the agent-specific dataset is removed and no
longer exists. Otherwise, the agent-specific length and
timestamp attributes for an agent-specific dataset shall
be updated whenever one of its attributes changes
value.
8.2.2 Recipe Origination — A recipe may be originated
by the create recipe operation and by the copy recipe
operation. The copy recipe operation creates a duplicate
of an original recipe and assigns it a new identifier. All
SEMI E42-0704 © SEMI 1995, 2004 50
of the attributes of the original are copied directly.
These operations are included in Namespace
Management in Section 9.4.1.
8.2.2.1 Create Recipe — A recipe is created when a
recipe body is first entered into a namespace and
assigned a new identifier. The recipe's mandatory
attributes are set. All other attributes take on their
default values. The values for the attributes
BodyLength
, EditTime, and EditedBy are required to be
provided by the initiator of the create operation. The
attribute BodyFormat
is also provided at this time if it is
not in source form (i.e., if BodyFormat
has a non-
default value).
A newly created recipe has an active state model
(Figure 8.7). The recipe is in the UNVERIFIED,
UNLINKED, UNAPPROVED, UNPROTECTED, and
UNCERTIFIED states.
The create recipe operation is invoked with the
RMNCreate service.
8.2.2.2 Update Recipe — The update operation is
identical to that of create except that an unprotected
recipe with the specified identifier already exists, and
the new body replaces the existing body. Attributes
concerning the body are provided by the initiator of the
request, as for the create operation. All non-mandatory
attributes are cleared (reset to their default values).
Any existing agent-specific datasets are discarded.
The update recipe operation is invoked with the
RMNUpdate service.
8.2.3 Recipe Building — Building a recipe is a two-step
process. First the recipe is verified and then linked.
8.2.3.1 Verify Recipe — The verify operation is the
only time it is necessary to parse the contents of the
recipe body until the recipe is executed. The primary
purpose of this process is to ensure that the syntactical
and lexical structure of the body is correct. One or more
checks for semantic correctness may also be performed
as part of the verification operation, but this is not
required.
Actual verification is performed by a member agent's
recipe executor at the request of a namespace
manager. For this reason, this operation is also
discussed under namespace management in Section
9.4.7.
Recipes may be stored in a namespace in an incomplete
or unfinished form. For recipes in source form, the
verification procedure shall be performed only at the
request of the user. It shall not be performed
automatically.
There are four attributes affected by the verification
operation: Verified
, EstRunTime, ExtRef, and
Parameters
.
The boolean generic attribute Verified
is used to
indicate the recipe's state with respect to this procedure.
Verified
is cleared when a recipe is first created and
whenever it is updated. Verified
is set TRUE only when
the recipe passes the verification by a recipe executor.
A recipe is considered to be verified if, and only if, the
Verified attribute is TRUE. Figure 8.2 illustrates the
recipe's VERIFICATION state. For a description of the
transitions, see Table 8.1 in Section 8.3.
Figure 8.2
Verification State Model
The values for the attributes EstRunTime
, ExtRef,
Parameters
, and VerificationID are returned (where set)
by the recipe executor when the verification has been
successful. If the operation is unsuccessful, they shall
be cleared.
ExtRef
contains a list of all external references found
within the body of the recipe by the recipe executor.
These references may be explicit
or implicit, leaving
the class and/or version unspecified.
The verify recipe operation is invoked with the
RMNAction service.
8.2.3.2 Link Recipe — The link operation is a required
operation that may be requested at any time by the
operator or supervisor. Successful completion of the
link operation indicates that the recipe is ready for
execution. For single-part recipes without variable
parameters, linking consists only of setting the generic