semi合集-English.pdf - 第1765页

SEMI E42-0704 © SEMI 1995, 2004 34 5.3 Distributed Recipe Namespace Issues — This section introduces issues that are ap plied to more than one object within the distributed recipe namespace capability. 5.3.1 Object Servi…

100%1 / 7923
SEMI E42-0704 © SEMI 1995, 2004 33
5.2 Overview — The DRNS object model (Figure 5.2) is a specialization of the model introduced in Section 4. The
distributed recipe namespace, the DRNS segment, and the DRNS manager are subtypes of the recipe namespace, the
recipe namespace segment, and the recipe namespace manager respectively. Each inherits the attributes and
operations of its corresponding supertype. Only those attributes and operations that are specific to the DRNS types
are shown in object representations.
Figure 5.2
Distributed Recipe Namespace Model
The namespace supertype has exactly one segment of storage. Where storage is centralized, the segment is internal
and private to the namespace. However, in the case of the distributed recipe namespace, there may be multiple
DRNS segments, each provided by a separate agent. For this reason, the DRNS segment is a standardized object.
The distributed recipe namespace separates the management of recipes within a specific recipe storage area from the
management of the entire namespace. The management of individual recipes within a specific storage area is
delegated to the distributed recipe namespace segment. The distributed recipe namespace manager manages the
various segments and the namespace itself. The manager is responsible for knowing the identifiers of all recipes
stored in the entire namespace. It requires a knowledge of the structure of the recipe's identifier and the significance
of the version in differentiating between recipes of the same name and different versions.
The DRNS recorder provides a backup facility for information required to automate the rebuilding of a distributed
recipe namespace. It is external to the DRNS namespace and to its DRNS manager.
SEMI E42-0704 © SEMI 1995, 2004 34
5.3 Distributed Recipe Namespace Issues — This
section introduces issues that are applied to more than
one object within the distributed recipe namespace
capability.
5.3.1 Object Services — Attachment is a relationship
between a managed object and its manager that is
defined in OSS (SEMI E39). One object may be
attached, detached, and reattached to a manager. When
attached, the managed object is able to recognize that
certain critical services have been requested by its
manager. The segment and recorder objects shall
comply with requirements for the operations and
services defined in SEMI E39 (OSS) to attach, detach,
and reattach to and from a DRNS manager. They shall
also allow their manager to modify specified attributes
that are otherwise read-only.
The ability to create and delete a segment or recorder is
optional.
The authorized user may request a DRNS manager to
attach or detach a specified segment or recorder.
5.3.2 Logical Recipe — A logical recipe is defined as
a recipe with a specific body and a specific set of
generic attribute values. Every managed recipe stored
is an instance of a logical recipe.
In a distributed recipe namespace, it is normal for
instances (copies) of a given logical recipe to exist in
more than one DRNS segment at any time. In other
words, multiple duplicate copies of a recipe with the
same identifier may co-exist within the distributed
recipe namespace. To retain the integrity of the
namespace, this can be allowed if, and only if, each
copy of a recipe with a given identifier is an instance of
the same logical recipe. It is the responsibility of the
DRNS manager to ensure this logical identity is
maintained.
Agent-specific datasets are not included in the
definition of the logical recipe because multiple agent-
specific datasets may exist independently of one
another, and only the dataset specific to the agent
providing the DRNS segment is normally kept in that
segment.
5.3.3 Change Requests — A change request occurs
whenever a user, an external application, or an attached
DRNS segment requests the DRNS manager to make, or
permit, any change in a recipe. Information concerning
change requests is kept in the form of logical change
request records. Once a change request is made, a
change request record is created and maintained until
the change has been either completed or discarded.
Because the information represented by change request
records is publicly available, they provide a degree of
diagnostic capability.
The change request record is not a formal or
standardized object, but it represents the information
that is available through services.
Change management is the most critical issue of the
DRNS capability and is discussed in detail in different
sections below.
5.4 Distributed Recipe Namespace Segment — The
distributed recipe namespace segment (Figure 5.3) is
responsible for all of the activities that directly
manipulate recipes, including storage, retrieval,
deletion, and operations that change a recipe's attributes
or body. This requires a micro-level knowledge of the
recipe's identifier, its structure, the inter-relationships
between the various recipe attributes, how the recipe is
stored, and how it is transferred. It also includes a
macro-level knowledge of all of the identifiers of the
recipes that it has stored. The DRNS segment shall
ensure that only one recipe with a given identifier exists
within that DRNS segment. The contents of an
unattached DRNS segment shall be read-only.
A DRNS segment and its storage are provided by an
agent, which could be equipment, an independent
“recipe server”, or other factory systems.
Figure 5.3
Distributed Recipe Namespace Segment
5.4.1 Master and Dedicated Segments — A master
segment is a specialization of a DRNS segment that is
capable of storing multiple agent-specific datasets per
recipe. Master segments are not dedicated to a single
equipment and are used to store a full copy (including
all existing agent-specific datasets) of all logical
recipes within the namespace. It is required that every
SEMI E42-0704 © SEMI 1995, 2004 35
distributed recipe namespace manager be capable of
supporting at least one attached master segment.
Additional master segments may be desirable for
further backup protection.
The term dedicated segment is used to refer to
segments that are not master segments. Dedicated
segments store at most one agent-specific dataset per
recipe. Because a DRNS segment provided by
equipment would not expect to keep agent-specific
datasets for other equipment, equipment normally does
not provide master segment capability.
Master and dedicated segments have the same
attributes and support the same message services, but
they respond differently to agent-specific datasets and
are used for different purposes. A master segment
requires approval prior to changing an agent-specific
dataset.
5.4.2 Change Restrictions — The DRNS segment may
provide access to recipes within its storage to the other
components of the agent providing the storage.
However, neither the generic attributes nor the body of
recipes stored by the segment shall be changed except
with the explicit approval of the distributed recipe
namespace manager.
Dedicated DRNS segments that are attached to a DRNS
manager may change the contents of an agent-specific
dataset without first asking permission. However, they
are required to notify the manager of any change as
soon as it occurs.
The attribute RecipeReadOnlyLevel
is set by the DRNS
manager to the value of the corresponding namespace
RecipeReadOnlyLevel
attribute when the segment is
first attached and whenever the namespace attribute is
changed. This attribute has the same function as the
namespace attribute and allows the segment to prohibit
changes based on a recipe's approval level as defined in
Section 8.2.5. For example, the segment shall deny
requests to modify a write-protected recipe.
The DRNS segment is prohibited from changing its
contents whenever it is unattached. However, recipes
and recipe attributes may be read at any time by other
entities, including other components of the owner
agent.
Any changes to a logical recipe stored by the DRNS
segment shall first be approved by the DRNS manager
before
the change is made. This includes any changes to
the body or to any generic attribute. This is required for
two reasons. First, two different DRNS segments may
attempt to change a recipe at the same time, and this
activity must be coordinated. Second, to protect the
integrity of the recipe identifier where multiple
instances of a recipe exist, the distributed recipe
namespace is required to ensure that all such instances
have been updated appropriately with that change
before other changes to the same recipe are allowed.
NOTE: The prohibition against unauthorized change
does not preclude the saving of such changes external
to the DRNS segment while waiting for authorization.
However, changes made by other DRNS segments,
subsequent to such changes and prior to authorization,
may invalidate these changes.
Communications between the different components of
an agent that do not require or use the formal services
defined by RMS are considered as proprietary to the
agent and are neither covered nor excluded by RMS,
subject to the above restrictions against change.
Figure 5.4
Distributed Recipe Namespace Recorder
5.5 Distributed Recipe Namespace Recorder — The
distributed recipe namespace recorder provides a
method of externally storing and retrieving information
critical to automated rebuilding of a damaged
distributed recipe namespace. It contains two types of
information: a list of the DRNS segments that are
attached to the DRNS manager and the current change
request record in process per recipe.
A DRNS recorder may be attached and detached from a
DRNS manager, and reattached to that manager.
Information that it contains is available to anyone but
may only be changed by its manager.
The DRNS recorder is able to store the DRNS segment
specifiers (the object specifiers) of the attached DRNS
segments in its Segments
attribute. This information
allows a distributed recipe namespace to be
automatically rebuilt in the event that the namespace, or