semi合集-English.pdf - 第1800页
SEMI E42-0704 © SEMI 1995, 2004 69 The object specifier for an object ow ned by a DRNS manager is formed by concat ena ting the object type and identifier for either the manager or the namespace , followed by the object …
SEMI E42-0704 © SEMI 1995, 2004 68
10.2.1.1 Attribute Read/Write — The DRNS distributed
recipe namespace recorder shall support the get
attributes operation for its attributes. It shall deny
attempts to set its attributes through the set attributes
service.
10.2.1.2 Object Create and Delete Operations — The
recorder may support both the create object and delete
object 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 recorder shall be attached to a
specific manager before it is ready to accept data. Once
created, the recorder shall set its attributes other than
ObjID
to null or empty values.
The create and delete operations are not required if the
owner agent that provides the distributed recipe
namespace recorder capabilities provides an installed
distributed recipe namespace recorder that cannot be
deleted. In this case, a means of recreating the recorder
shall be provided in the event the recorder becomes
damaged. If either of these two operations is supported,
both are required.
10.2.1.3 Object Attachment Operations — The
recorder shall support the operations to attach and
reattach to a DRNS manager, and the detach and attach
set attributes when invoked by the DRNS manager to
which it is attached.
The recorder attributes Namespace
and Namespace-
Manager are set by the attach and reattach operations.
The detach operation breaks the logical connection of
the recorder to the namespace and managers by setting
the recorder attributes Namespace
and Namespace-
Manager to null values.
NOTE: In the event that a distributed recipe namespace
becomes damaged, its recorder should be left attached
so that it may later be reattached to a new manager.
The reattach operation is used in rebuilding a
distributed recipe namespace.
10.2.2 Add Segment Record — The add segment
record operation adds a given segment (its object
specifier) to the DRNS recorder's internal list of DRNS
segments. A request to add a DRNS segment that is
already in the list shall be denied.
The add segment record operation is invoked by the
service RMDRAddSegRecord.
10.2.3 Delete Segment Record — The delete segment
record operation deletes a given segment specifier from
the DRNS recorder's internal list of DRNS segments. A
request to delete a segment not in the current list shall
be denied.
The delete segment record operation is invoked by the
service RMDRDelSegRecord.
10.2.4 Add Change Request Record — The add
change request record operation adds a change
request record to the DRNS recorder. The DRNS
recorder keeps, at most, one change request record per
recipe at any time. This is intended to represent a
change currently approved and active for that recipe. If
the DRNS recorder already has a change request record
for the specified recipe, the information in the new
change request replaces the previous information.
The contents of the change request record are defined
in Section 10.3.7.4.
The add change request record operation is invoked by
the service RMDRAddChgRecord.
10.2.5 Delete Change Request Record — The delete
change request record operation removes a change
request record for a specified recipe.
The delete change request record operation is invoked
by the service RMDRDelChgRecord.
10.2.6 Get Change Request Record — The get change
request record operation returns the current change
request record for a specified recipe or assigned
segment.
The get change request record operation is invoked by
the service RMDRGetChgRecord and is available to
any service user.
10.3 Distributed Recipe Namespace Management
Operations — Operations defined in Sections 8 and 9
shall be supported by the DRNS manager. This section
defines the additional operations provided by the DRNS
manager. Operations defined in Sections 8 and 9.4 are
delegated by the DRNS manager to an attached DRNS
segment.
10.3.1 Object Services — The DRNS manager is
considered to own the DRNS segments and any DRNS
recorder currently attached to the distributed recipe
namespace. In addition to the object services required
in Section 9, the DRNS manager shall support the get
type and get attribute name operations for its attached
objects. The DRNS manager shall support object
services directed to any of its attached objects and to
recipes stored by specific DRNS segments.
The DRNS manager is considered to own the recipes
that are owned through delegation by any of its attached
DRNS segments. The Get Attributes and Set Attributes
operations for a recipe may be directed to the
distributed recipe namespace.
SEMI E42-0704 © SEMI 1995, 2004 69
The object specifier for an object owned by a DRNS
manager is formed by concatenating the object type and
identifier for either the manager or the namespace,
followed by the object type and identifier of each
owned object in the ownership hierarchy. An example
of the object specifier for a recipe XYZ;3 stored by
DRNS segment ABC_Etch_Seg within the distributed
recipe namespace WetEtch003 would be:
"RNSD:WetEtch003>RNSDSegment:ABC_Etch_
Seg>MRcp:XYZ;3"
If an agent or a DRNS segment is specified, then the
DRNS manager shall delegate the operation to the that
segment. Otherwise, the operation shall be delegated to
a master segment.
A request to set one or more read-write attributes of a
recipe is treated by the DRNS manager as a change
request.
10.3.2 Delete Distributed Recipe Namespace — A
distributed recipe namespace with attachments may not
be deleted.
The delete distributed recipe namespace operation is
invoked by the service RMNDeleteNS defined in
Section 9.2.2.
10.3.3 Attach and Detach Supervised Objects — This
section defines the support required for the authorized
user to request a DRNS manager to attach or detach one
or more segments or a recorder. The operations and
services are defined in detail in SEMI E39 (OSS).
10.3.3.1 Attach Supervised Object — The attach
supervised object operation is invoked by an
authorized user to request the DRNS manager to attach
a specified unattached segment or recorder.
When a request to attach a supervised object is
accepted, the DRNS manager sends an attach or detach
request to the specified object.
The DRNS manager shall have the capability of
managing at least one attached dedicated and one
attached master segment at a time. At most, one
recorder shall be attached to a DRNS manager at any
given time.
Once attached, the segment or recorder becomes a
formal part of the namespace and is owned by the
manager.
When adding attachments to a DRNS manager, the
recorder should be added first, so that it may be used to
record the segments as they are subsequently attached.
When the distributed recipe namespace manager
receives a request to attach a segment, it sends that
request to the specified segment. If the operation is
successful, and if a recorder is attached, the manager
requests the distributed recipe namespace recorder to
record the segment specifier (the object specifier for the
segment). If the agent providing the segment is not
already in the namespace attribute Members
, it is added
at this time.
The operation of attaching a recorder shall set the
distributed recipe namespace attribute Recorder
to the
value of the recorder's attribute ObjID
. The operation
of attaching a segment shall add the segment specifier
to the Segments
attribute of the distributed recipe
namespace.
When a recorder is attached, all subsequent operations
that attach and detach segments shall update the
recorder through its operations to add and remove a
record of the segment.
Specifiers used in the namespace attributes Recorder
and Segments
, and segment specifiers stored in the
DRNS recorder, shall use the form including the
specifier for the agent providing the capability for the
recorder or segment. This is required for identification
outside the scope of the current namespace. For
example, if it later becomes necessary to rebuild the
distributed recipe namespace, then the segment must be
located through its agent owner rather than through the
namespace.
10.3.3.2 Detach Supervised Object — An attached
segment or recorder may be detached at any time. The
manager forwards the request to the specified object.
When a segment is detached, if a recorder is attached,
then the manager requests the recorder to remove the
segment that is being detached.
The user may request a DRNS manager to detach an
attached recorder or segment at any time. When a
recorder is detached, the distributed recipe namespace
attribute Recorder
shall be set to a null value. When a
segment is detached, its specifier is removed from any
attached recorder and from the Segments
attribute of
the distributed recipe namespace.
10.3.4 Change Request Management — A change
request occurs whenever the DRNS manager receives
any request, from any source, to change a recipe or the
contents of the distributed recipe namespace as a
whole. This includes requests to change the recipe
identifier, a generic attribute, an agent-specific
attribute, or the body of an existing recipe. It also
includes all changes that affect the set of recipe
identifiers within the distributed recipe namespace.
Requests for changes may come from a source that is
either internal or external to the namespace.
10.3.4.1 External Change Requests — The DRNS
manager may receive a request, through recipe
SEMI E42-0704 © SEMI 1995, 2004 70
management services, to change a recipe, or to change
the namespace (for example, to store a new recipe or
delete an existing one), from an entity other than an
attached DRNS segment. If the change involves a
specified agent (for example, verify or upload requests),
then the DRNS manager shall delegate the operation to
the DRNS segment provided by that agent. Otherwise,
operations are preferably delegated to a DRNS master
segment.
10.3.4.2 Internal Change Requests — A change
request may be initiated by a specific attached segment.
For example, a local operator may want to change the
generic attribute EditedBy
(illustrated in Figure 10.3) or
to rename a recipe. The DRNS segment then requests its
DRNS manager for approval to make the specific type
of change desired. The DRNS manager, upon receipt of
the request, shall create a change request record
(Section 10.3.4.4) for the recipe(s), specifying the
DRNS segment that initiated the request, the type of
change requested, and noting that the change was
segment-initiated.
10.3.4.3 Allowable Change Requests — A change
request may not be allowable. For example, a change to
a write-protected recipe or a change to introduce a
recipe identifier already in use may be denied
immediately. If the change is allowed, then a change
request record shall be created in non-volatile memory
for each allowed change request.
Any operation that creates or changes a recipe body, a
recipe attribute, or a recipe identifier, requires explicit
manager approval. This includes the following
operations: create, delete, modify (body), copy (new
identifier), rename (new identifier), protect, verify, link,
unlink, certify, de-certify, change read-write generic
attribute, and change read-write agent-specific
attribute.
The following requirements shall apply:
— A request to create a new recipe, or copy an existing
recipe, with a specified identifier shall be granted
only if that identifier is not in use for a write-
protected recipe within the namespace as a whole
(that is, no attached DRNS segment has a write-
protected recipe using that identifier).
— A request from a DRNS segment to rename a recipe
shall be granted only if no other segment has that
recipe and the new identifier is not otherwise in use.
— A request from a dedicated segment to delete a
recipe shall be denied only if the recipe is write-
protected.
10.3.4.4 Change Request Record Definition — A
change request record, as shown in Figure 5.7,
consists of the following information:
— The recipe identifier (RecipeID
),
— a destination recipe identifier (DestRecipeID
) (used
for copy and rename only, and otherwise null),
— the segment specifier, (Segment
), of the DRNS
segment that has requested a change or to which the
change operation is or will be delegated,
— the specific type of change requested (ChangeType),
— a timestamp of when the request was received
(Timestamp
),
— an operation identifier (OperationID
), an integer
delegated by the DRNS manager that uniquely
identifies a given change request within the
distributed recipe namespace at large,
— a boolean (SegmentRequest
) used to differentiate
requests by attached segments from other requests
(the manager responds differently in the two cases).
All of the above information, with the exception of the
segment specifier, shall be determined at the time the
change request record is created. In the case of
externally initiated requests, delegation of a segment
specifier may be postponed until the change request is
selected.
The operation identifier is used to identify a specific
change request by both the namespace and the
delegated DRNS segment. It is passed to the DRNS
segment when granting permission to make the
requested change (Section 10.3.5) and when sending
segment change approval to a DRNS segment (Section
10.1.2.2) for a previous change request made while the
recipe was locked. It shall also be used for recipe
management services defined in Section 12 that use an
operation identifier (parameter RMOpID).
For change requests initiated by an attached segment,
the boolean SegmentRequest
is set to TRUE.
Otherwise, it is FALSE.
The change request record shall be deleted when the
requested change operation has been completed,
whether successfully or unsuccessfully.