semi合集-English.pdf - 第1795页
SEMI E42-0704 © SEMI 1995, 2004 64 The sele ction of even ts to be repor ted, and th e mechanisms for reporting these events, are define d in SEMI E53 (Event Reporting) . 10 Distributed Recipe Namespace Management Operat…
SEMI E42-0704 © SEMI 1995, 2004 63
attribute of the agent-specific dataset for the recipe
executor’s agent. Note that attributes of a recipe may
change without affecting the version number.
Synchronization may fail either through failure to
properly upload an execution recipe, through failure to
properly retrieve the value of the execution recipe’s
ExecLinkParam
attribute, or through failure to
successfully rename the recipe stored by the recipe
executor. The attribute SynchFail
contains a list of
recipe specifiers of the execution recipes for which
synchronization was attempted but failed to be
successfully completed. A recipe specifier shall be
deleted from SynchFail
if a later attempt at the failed
operation for that recipe is successful. The authorized
user may also remove one or all recipe specifiers from
this attribute.
The attribute SynchOn
is set by the user to indicate the
types of changes for which synchronization shall be
performed. SynchOn
may be set to specify synchroniz-
ation for changes to the body, changes to the last value,
creation of a new recipe, building a new derived object
form recipe from a source form, or any combination of
these settings. A value of zero disables synchronization.
SynchOn
is an unsigned integer. Possible values are
either 0 (disabled) or any combination (sum) of one or
more of the following decimal values:
0 = synchronization disabled
1 = changes in body
2 = new execution recipes
8 = changes in the last value of one or more
variable parameters (i.e., to the ExecParam
attribute of the execution recipe)
16 = new derived object form execution recipes
NOTE: Where possible, the values of SynchOn
and
ExecChgCtrl
address the same change issues. For this
reason, a value of 4 is not used, and a new value of 16
is added.
9.6 Table of Operations — Table 9.1 lists all the
operations defined for namespace management.
The column labeled “Rqmt” is used to indicate those
operations that are required for fundamental compliance
to RMS as a recipe namespace resource.
Table 9.1 Namespace Operations
Operation Description Rqmt
create namespace A new namespace is created and assigned an identifier. N
delete namespace A namespace is deleted. N
rename namespace The namespace identifier is re-assigned. N
get available storage Determine the amount of recipe storage available. Y
check recipe status Determine the existence and read-only status of a recipe, and obtain the next numeric version. Y
get best version Determine the default version for a given recipe class and name and for an optional agent. Y
create recipe A new recipe body is entered into the namespace. Y
delete recipe A recipe's identifier is removed from the namespace. Y
store recipe A recipe is stored in a namespace. Y
retrieve recipe A recipe is sent from the namespace. Y
copy recipe A new recipe is originated as a copy of an existing recipe. N
rename recipe A recipe is assigned a new identifier. N
verify recipe Check the syntax or format of a recipe body for correctness. Y
download recipe A recipe is downloaded to a specified agent's recipe executor. Y
upload recipe A recipe is created or updated by uploading a recipe body from a specified agent's recipe
executor.
N
9.7 Namespace Events — A user of recipe namespace services is potentially interested in any change that occurs to
or within a namespace that was not initiated by the user itself. Two such events are defined: Recipe Namespace
Change and Recipe Change. A Recipe Namespace Change event occurs when a namespace is created, deleted, or
renamed, or when a recipe is created, deleted, copied, or renamed. A Recipe Change event occurs whenever the
body or any of the attributes, including agent-specific attributes, of an existing recipe is changed.
SEMI E42-0704 © SEMI 1995, 2004 64
The selection of events to be reported, and the
mechanisms for reporting these events, are defined in
SEMI E53 (Event Reporting).
10 Distributed Recipe Namespace
Management Operations
This section defines the operations required for the
distributed recipe namespace capability. Operations are
defined for the DRNS segment, the DRNS recorder, and
the DRNS manager, in that order. Support for the
distributed recipe namespace capability is not required
for RMS compliance.
10.1 Distributed Recipe Namespace Segment
Operations — This section defines the operations that
shall be supported by the distributed recipe namespace
segment.
10.1.1 Object Services — The DRNS segment is
considered to own the recipes that it stores.
The segment specifier is the object specifier for a
DRNS segment and has the form
"type1:id1>...>type2:id2". An attached DRNS segment
is owned by the agent providing the DRNS segment
capabilities, by the distributed recipe namespace of
which it is a component, and by the DRNS manager to
which it is attached, and shall be accessible by any of
these three paths. An unattached DRNS segment is
owned by the providing agent.
An example of a segment specifier for a DRNS segment
named ABC_Etch_Seg, a component of a namespace
named WetEtchA provided by an agent named
WetEtch003, is
"Agent:WetEtch003>RNSD:WetEtchA>RNSDSegmen
t:ABC_Etch_Seg".
For a master segment Alpha provided by agent
RecipeServer, this becomes
"Agent:RecipeServer>RNSD:WetEtchA>RNSDMaster
:Alpha."
NOTE: The form of the specifier used for DRNS
segments and DRNS recorders will vary. For example,
to specify a segment to be attached to a DRNS manager,
the specifier must include the object type and identifier
for the agent providing the segment capability. Once
the segment is attached, it may be specified through the
namespace hierarchy, as in the example above.
10.1.1.1 Attribute Read/Write — The DRNS segment
shall support the get attributes operation for itself and
all recipes that it has stored.
It shall support the set attributes operation for its
recipes only according to the restrictions against change
defined in Section 5.4.2 and within Section 10.1.
If requested to change read/write attributes, it shall
request and receive permission to change attributes
prior to making such change.
A request to change either several generic attributes at
the same time, or several agent-specific attributes for a
specific agent-specific dataset at the same time, is
considered for approval purposes as one change.
However, changes to both generic and agent-specific
attributes shall not be included in one change request or
change.
10.1.1.2 Create and Delete Operations — The segment
may support both the create object and delete objects
pair of operations. The authorized user who invokes the
create object operation shall assign a name to be used as
its name ObjID
. The name "Default" is prohibited.
Once created, the segment shall be attached to a
specific manager before it is permitted to accept
recipes.
The create and delete operations are optional if the
owner agent that provides the distributed recipe
namespace segment capabilities provides an installed
distributed recipe namespace segment that cannot be
deleted. In this case, a means of recreating the segment
shall be provided in the event the segment becomes
damaged. If one of these two operations is supported,
both are required.
The attributes Namespace, NamespaceManager, and
RecipeReadOnlyLevel
shall be set to null values at the
time the segment is created.
A segment that is attached or that contains recipes (is
not empty) shall not be deleted.
10.1.1.3 Object Attachment Operations — The
segment shall support the operations to attach and
reattach to a DRNS manager, and also the operations
invoked by its manager to detach itself from a DRNS
namespace manager. It shall also support the attach set
attributes operation. Certain RMS operations shall be
accepted only when received from its manager, as
indicated below.
All requests for changes to recipes within the segment
shall be sent to the DRNS manager to which it is
attached.
The manager shall set the segment attributes
Namespace
, NamespaceManager, and RecipeRead-
OnlyLevel when attaching or reattaching a segment. It
may change these attributes for an attached segment at
any time.
The detach operation breaks the logical connection
between the segment and its manager. The segment
becomes unattached, and the values of Namespace
,
NamespaceManager
, and RecipeReadOnlyLevel are set
SEMI E42-0704 © SEMI 1995, 2004 65
to a null value. All recipes and recipe attributes are
considered as read-only during the time the segment is
unattached.
The reattach object operation is used in rebuilding a
distributed recipe namespace. This operation sets the
value of the attribute NamespaceManager
to the name
of the new manager. The segment returns a new token
value to the manager.
The request to reattach itself serves to inform the
segment that any of its pending change requests not
previously approved have now been forgotten. The
segment should either discard the request or resubmit it
to its new manager.
10.1.2 Segment Recipe Management Operations —
Within a distributed recipe namespace environment, all
recipe management operations (Section 8) and
namespace recipe operations (Section 9.4) are
performed by the DRNS segment. The DRNS segment
shall support all operations defined in these sections.
Operations defined in Section 9.4 that involve a recipe
executor, such as download and upload, shall be
performed only with a recipe executor that is either
owned by the agent providing the DRNS segment
capability or is owned by a component within the
internal hierarchy of that agent. For example, a DRNS
segment provided by a cluster tool may download to a
recipe executor owned by a cluster module but not to
equipment external to the cluster.
Figure 10.1
Segment-Initiated Change Request Message Flow
10.1.2.1 Requirements for Approval — Operations that
change a recipe in any way shall be denied unless the
DRNS segment is attached to a DRNS manager. All
changes to logical recipes within a DRNS segment shall
be approved by the DRNS manager before the changes
are made to the recipe stored within the DRNS segment.
Changes to agent-specific datasets stored by attached
dedicated segments are pre-approved. This is possible
since, at most, one dedicated segment has an agent-
specific dataset for a specific agent for any given
recipe. However, the segment shall notify its manager
immediately after any such change by sending the
RMDNotify notification, which shall include the
attribute AgentSpec_Agent
, to identify the agent-
specific dataset, as well as all agent-specific attributes
that changed, regardless of whether they have been
reset to their default value or set to a non-default value.
(Otherwise, the entire agent-specific dataset would be
required.)
A master segment, however, is prohibited from
changing an agent-specific dataset without explicit
permission from the manager.
Requests for changes that are made with RMS services
defined in Section 12 may be sent from any service
user, including the DRNS manager. The DRNS segment
may reject requests for invalid changes, such as a
request to modify a read-only recipe. Otherwise, the
DRNS segment shall request approval from its DRNS
manager for each change (Section 10.3.5). The
manager responds by either approving, denying, or
putting the request on hold.
NOTE: Service requests sent directly to a DRNS
segment may not, in some circumstances, be fulfilled.
If the change request is denied, then the change is
prohibited immediately. If it is put on hold, the segment
shall retain the information necessary to effect the
desired change at a later time.
If the change request is approved, the DRNS segment
shall proceed with the change and shall notify its DRNS
manager when the change is completed, either normally
or abnormally, through sending the notification
RMDComplete with the results, as illustrated in Figure
10.1.
The DRNS manager will put a change request on hold
when another change request exists for the same recipe
and the recipe is locked. In this case, the DRNS
manager responds to the segment's change request with
an operation identifier that the manager uses later when
sending a segment change approval request.