semi合集-English.pdf - 第1796页
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 segme nt is unattached. The reattach object operatio n is used in rebuilding a distri…
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.
SEMI E42-0704 © SEMI 1995, 2004 66
Figure 10.2
Message Flow for Manager Approval of Change
Request
10.1.2.2 Segment Change Approval — The DRNS
segment may receive a segment change approval
request for an action that the DRNS segment had earlier
requested. This informs the DRNS segment that an
earlier change request made by the DRNS segment has
now been approved for immediate action or has been
completely denied.
The segment shall respond in one of three ways:
— It may reject the approval due to changes in
circumstances since the original request was made
(Figure 10.2(a).
— It may first fulfill the change request and then
respond that the change request has now been
completed, either successfully or unsuccessfully
(Figure 10.2(a).
— It may first respond that it accepts the change
request and then attempt to complete the change.
When change request has been completed, normally
or abnormally, the segment shall notify the manager
of the results with the RMDComplete notification
service (Figure 10.2(b).
Rejection of segment change approval shall be used
when the change is no longer desired. For example, a
DRNS segment "S" may request to link a write-
protected recipe, and the manager responds that the
request is on hold. Before the segment receives
approval for that change, the same logical recipe is
linked by a different attached DRNS segment, and the
results are updated to each DRNS segment having a
copy of the logical recipe, including segment "S". In
this case, the recipe may not be relinked.
11
The segment change approval operation is invoked by
the message service RMDSApproveAction by the
segment's DRNS manager and is otherwise invalid.
10.1.2.3 Scenario of a Segment Change Request — A
typical scenario is illustrated in Table 10.3.
In this scenario, a local operator wants to change the
generic attribute EditedBy
. The segment requests
approval for a generic attributes change. However, an
active change request exists for this recipe.
11 Both the DRNS manager and the DRNS segment are responsible
for compliance to RMS namespace requirements