semi合集-English.pdf - 第1764页
SEMI E42-0704 © SEMI 1995, 2004 33 5.2 Overview — The DRNS object model (Figure 5. 2) is a specialization of the m odel introduced in Section 4. T he distribute d recipe namespace , the DRNS segment, and the DRNS manager…
SEMI E42-0704 © SEMI 1995, 2004 32
Figure 5.1 illustrates a distributed recipe namespace with four segments, each provided by a different agent, and
each agent also having a local namespace.
Figure 5.1
Illustration of Agents, Segments, and Local Namespaces
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