semi合集-English.pdf - 第1803页

SEMI E42-0704 © SEMI 1995, 2004 72 Table 10.5 A cti ve Cha nge Request Negotiations Manager Segment Externally Initiat ed Change Request An externally initiated change request becomes active. The manager requests the del…

100%1 / 7923
SEMI E42-0704 © SEMI 1995, 2004 71
Figure 10.3
Change Request Record State Model
10.3.4.5 Change Request Lifecycle — This section
describes the states of a change request.
A change request is received and examined. It is
determined either to be allowed or not allowed.
If the requested change is allowed, then a change
request record is created for the specified recipe by
saving the information required. The change request is
now INACTIVE and ON HOLD (see Figure 10.1). The
operations identifier is set to a unique unsigned integer.
If the change was initiated externally, a segment may or
may not be designated until the change request is
selected for approval. The remaining information is
filled at this time. The change request record is placed
in a queue for that recipe in non-volatile memory.
The change request remains on hold until the DRNS
manager selects it as the next change and it becomes
selected. If a segment has not already been designated,
then one is determined at this time. The selected recipe
may be discarded after evaluation due to changes in
circumstances since it was originally put on hold.
Otherwise, the change request becomes active, and the
change request record is added to any attached DRNS
recorder. The manager is ready to begin its
negotiations with the designated segment or to approve
a segment-initiated change request already in progress,
at this point.
These stages may occur in rapid succession if the
request is initiated by a segment and the recipe was not
locked.
Selection occurs in one of two ways: either a change
request is received when the specified recipe is
unlocked (Section 10.3.4.5), or else a currently active
change request completes, and a new change request is
selected from the queue of change request records on
hold for that recipe. Rules for selection may vary and
are beyond the scope of RMS. For example, rules could
be sequence-oriented (first-in, first-out), or they might
consider the types of operations specified. For example,
requests for verification might be given precedence
over requests to link.
When a selected change request becomes active, the
manager adds the change request record to any
attached recorder and begins negotiations with the
delegated segment.
If the change request was segment-initiated (Section
10.3.5), the segment change request is approved. The
DRNS manager shall initiate a segment change
approval to the DRNS segment (Section 10.1.2.2).
There are three possible scenarios for the negotiations
with the segment: an externally initiated request, an
internally initiated request from a segment when the
recipe specified was unlocked, and an internally
initiated request from a segment when the recipe
specified was locked. These three types of scenarios are
illustrated in Table 10.5. NOTE: In both of the first two
cases, the segment sends a request to make a change
with RMDChangeRequest.req. However, in the first
case, the initiation of that change request was external,
and the segment's request is its required response to any
change request that it receives.
SEMI E42-0704 © SEMI 1995, 2004 72
Table 10.5 Active Change Request Negotiations
Manager Segment
Externally Initiated Change Request
An externally initiated change request becomes active. The
manager requests the delegated segment to make the change:
RMNAction.req ->
The segment responds that it will make the change and notify
the requestor when done.
<- RMNAction.rsp
The segment requests approval to make the change:
<- RMDChangeRequest.req
The manager approves the request immediately:
RMDChangeRequest.rsp ->
The segment completes the change and notifies its manager:
<- RMDComplete.nfy
The segment notifies the requestor of the change (in this case,
its manager) that the change is complete.
<- RMNComplete.nfy
Segment-Initiated Change Request for Unlocked Recipe
The segment requests approval to make the change:
<- RMDChangeRequest.req
The manager approves the request immediately:
RMDChangeRequest.rsp ->
The segment completes the change and notifies its manager:
<- RMDComplete.nfy
The segment notifies the requestor of the change (in this case,
its manager) that the change is complete.
<- RMNComplete.nfy
The segment notifies the initial requestor of the change that the
change is complete:
RMNComplete.nfy ->
Segment-Initiated Change Request for Locked Recipe
The segment requests approval to make a change:
<- RMDChangeRequest.req
The manager puts the change request on hold:
RMDChangeRequest.rsp ->
The change request later becomes active. The manager now
approves the segment’s earlier request to change generic
attributes:
RMDSApproveAction.req ->
The segment responds that it intends to make the change:
<- RMDSApproveAction.rsp
The segment completes the change and notifies its manager:
<- RMDComplete.nfy
The segment notifies the initial requestor of the change that the
change is complete:
RMNComplete.nfy ->
SEMI E42-0704 © SEMI 1995, 2004 73
10.3.4.6 Change Request Completion — The DRNS
manager is informed of the completion of an approved
change either immediately or through a later
notification using the RMDComplete service.
There are two circumstances when a DRNS segment
notifies its manager that it has completed an approved
change, illustrated by Figures 10.1 and 10.2 (b) for the
services RMDSegChange and RMDSApproveAction
respectively.
Figure 10.2 (a) illustrates the case where the manager
approves an earlier change request and the segment
makes the change before responding. In this case,
RMDComplete is not sent. However, if the segment
responds before actually making the change, then it is
required to send the notification RMDComplete when
done.
When a requested change has been completed by the
delegated segment, it notifies its manager by sending
the notification RMDComplete as shown in Figures
10.1 and 10.2 (b). The type of change and results of the
change operation dictate how the change shall be
updated to the other attached DRNS segments of the
namespace. After all affected DRNS segments have
been properly updated, then the change request record
corresponding to the completed change shall be
removed from the queue. If there are still inactive
change requests, the next request is selected and then
made active.
All other DRNS segments with the same logical recipe
shall be updated as appropriate. A change in agent-
specific datasets only shall be updated to master
segments. A change to attributes only shall cause only
the attributes of other instances of that recipe to be
updated. If the logical recipe was changed, then all
segments having a copy of that logical recipe shall be
updated.
When all necessary updates have been performed, the
DRNS manager shall discard the change request
record. It shall either request its DRNS recorder to
remove the change request for that change or to add the
next change request to be approved. Then the DRNS
manager shall select another inactive change request. If
no further change requests exist for that recipe, the
DRNS manager shall remove the last change request
from any attached DRNS recorder.
10.3.4.7 Change Management Example — As an
example of change management, if an operator at
Equipment A wants to link Recipe R;3 within the
distributed recipe namespace D, the resulting changes
to the recipe's generic header must be passed to all
other attached DRNS segments within the namespace
that contain Recipe R;3 before any other change is
approved.
In this example, if a request from segment A to link
Recipe R;3 is received by the manager, and no inactive
requests exist, and if Recipe R;3 is not already both
linked and write-protected, and if the request is to be
approved, the DRNS manager creates a change request
record for that recipe, which locks the recipe. The
DRNS manager approves the request and denies
subsequent requests until the approved change has been
made and other segments with an instance of that recipe
have been updated appropriately.
10.3.5 Segment Change Request — The segment
change request operation is a request made by an
attached DRNS segment to approve a specific type of
change. The DRNS manager shall respond by either
approving the request, denying it, or putting it on hold.
When putting the requested change on hold, the DRNS
manager shall return the operation identifier delegated
in the corresponding change request record.
The segment change request operation is invoked with
the service RMDSegChange sent by an attached DRNS
segment.
10.3.6 Segment Action Complete — A DRNS segment
that has requested and received permission to change a
recipe shall notify the DRNS manager when the action
is complete, whether normally or abnormally. Also,
when the manager approves an earlier request made by
a segment, and the segment makes the change after
responding to the approval, the segment shall also
notify its manager of the completion of the change. The
notification allows the DRNS manager to request the
updated recipe and send it to other segments as
appropriate.
The segment action complete operation is invoked with
the service RMDComplete, sent by an attached
segment.
10.3.7 Segment Notification — A dedicated segment
shall notify its manager of any change to an agent-
specific dataset. These changes are pre-approved. They
are not preceded by formal requests for change and do
not generate change request records. Upon receiving
notification of such a change, the DRNS manager shall
update all master segments with the new agent-specific
dataset values. An example of this case is illustrated in
Table 10.6.
The segment notification operation is invoked with the
service RMDNotify, sent by an attached segment.