semi合集-English.pdf - 第1769页

SEMI E42-0704 © SEMI 1995, 2004 38 Objects that are subtypes of objects in troduced in Section 4 inh erit the attr ibutes of the supertype objects. These attributes are not repeated in this section. 5.11.1 Distributed Re…

100%1 / 7923
SEMI E42-0704 © SEMI 1995, 2004 37
Figure 5.7
Change Request Record
5.8.1 Change Management — A change request occurs
whenever a user or an attached segment requests the
distributed recipe namespace manager to make, or
permit, a specific type of change. A change request
record (Figure 5.7) contains information about who
requested what type of change. This allows later
diagnostics when necessary.
A change request record is created for a recipe
whenever an attached DRNS segment requests a change
and is deleted when the requested change has been
completed or discarded. A change request is either
inactive or active. Once a change request is made, it is
considered as inactive until the change has been
approved by the DRNS manager. Once approved, it is
considered as active.
The change request record is not a standardized object
and is not accessed directly through public services.
However, the information represented by the change
request record shall be available, upon request, from
the DRNS manager for all inactive and active change
requests. For this reason, it is convenient to model the
change request record as an object.
A recipe for which a change request exists is called
locked. Otherwise, it is unlocked.
The DRNS manager is responsible for ensuring that
only one change request per recipe is active at any
time. The results of each approved change request shall
be updated appropriately to each of the other DRNS
segments with a copy of the same logical recipe before
a subsequent change to the recipe is approved.
5.9 Building a Distributed Recipe Namespace — A
distributed recipe namespace is built up in several
stages. The distributed recipe namespace and its
associated DRNS manager are created separately in the
first stage. The individual DRNS segments are first
created and then attached to the DRNS manager. At
least one DRNS segment must be attached to the DRNS
manager before it can accept recipes, as the distributed
recipe namespace has no other means of storage. Figure
5.8 illustrates the attachment relationship.
Figure 5.8
The Attachment Relationship
The attached DRNS segments may later be detached
from the namespace and then either attached again to
the same namespace or to a different namespace
without affecting the recipes stored within the DRNS
segment.
NOTE: When a DRNS segment with existing recipes is
detached and then attached to a different namespace, its
recipe identifiers fall within the domain of the new
namespace. This may require some recipes to be
renamed before the attach process is complete.
5.10 Rebuilding a Damaged Distributed Recipe
Namespace — A distributed recipe namespace, or its
manager, may become damaged or unavailable. If a
DRNS recorder was attached to the damaged name-
space, then rebuilding the namespace can be automated.
A new distributed recipe namespace and new DRNS
manager are created, assigning the old namespace
name as the object identifier ObjID
for the new
namespace. The new DRNS manager should be
assigned a different identifier, however, as a security
measure. The user may then request the new DRNS
manager to rebuild the namespace with the old DRNS
recorder. A namespace may also be rebuilt without a
recorder if the list of segment specifiers can be
provided by the user. However, the user is not expected
to provide the information retained through change
request records.
5.11 Object Attribute Definition Tables — This section
contains the formal attribute definitions for the
distributed recipe namespace capability. Except for the
object identifier attributes, attributes are listed
alphabetically.
DRNS
Manager
DRNS
Segment
DRNS
Recorder
is attached to
is attached to
SEMI E42-0704 © SEMI 1995, 2004 38
Objects that are subtypes of objects introduced in Section 4 inherit the attributes of the supertype objects. These
attributes are not repeated in this section.
5.11.1 Distributed Recipe Namespace Segment Attribute Definition — Table 5.1 defines the attributes required for a
distributed recipe namespace segment, and Table 5.2 defines the attributes of the subtype master segment.
Table 5.1 Distributed Recipe Namespace Segment Attribute Definition
Attribute Name Description Access Rqmt Form
ObjType The object type. RO Y Text = “RNSDSegment”
ObjID The object name (identifier). RO Y Text.
Namespace The name (ObjID) of the namespace to which the
segment belongs. May be set by the manager.
RO Y Text.
NamespaceManager Identifies the distributed recipe namespace manager.
May be set by the manager.
RO Y Text.
RecipeReadOnlyLevel Used to track the corresponding attribute of the
namespace to which the segment belongs. May be set
by the manager.
RO Y Unsigned integer.
Table 5.2 Distributed Recipe Namespace Master Segment Attribute Definition
Attribute Name Description Access Rqmt Form
ObjType The object type. RO Y Text = “RNSDMaster”
ObjID The object name (identifier). RO Y Text.
5.11.2 Distributed Recipe Namespace Recorder Attribute Definition — Table 5.3 defines the attributes required for
a distributed recipe namespace recorder.
Table 5.3 Distributed Recipe Namespace Recorder Attribute Definition
Attribute Name Description Access Rqmt Form
ObjType The object type. RO Y Text = “RNSDRecorder”
ObjID Text. RO Y Text.
LockedRecipes List of identifiers of recipes with existing change
request records.
RO Y List of formatted text.
Namespace Identifies the namespace to which the recorder is
attached. May be set by the manager.
RO Y Text.
NamespaceManager Identifies the distributed recipe namespace manager.
May be set by the manager.
RO Y Text.
Segments List of specifiers of currently attached segments. RO Y List of formatted text.
5.11.3 Distributed Recipe Namespace Attribute Definition — Table 5.4 defines the attributes required for a
distributed recipe namespace.
Table 5.4 Distributed Recipe Namespace Attribute Definition
Attribute Name Description Access Rqmt Form
ObjType The object type. RO Y Text = “RNSD”
ObjID Text. RO Y Text.
LockedRecipes A list of identifiers of all recipes with existing change
request records.
RO Y List of formatted text.
Recorder The recorder specifier of the attached distributed
recipe namespace recorder.
RO Y Text.
Segments A list of specifiers of the distributed namespace
segments attached to the namespace.
RO Y List of formatted text.
SEMI E42-0704 © SEMI 1995, 2004 39
5.11.4 Distributed Recipe Namespace Manager Attribute Definition — Table 5.5 defines the attributes required for
a distributed recipe namespace manager.
Table 5.5 Distributed Recipe Namespace Manager Attribute Definition
Attribute Name Definition Access Rqmt Form
ObjType The object type. RO Y Text = “RNS_MgrD”
ObjID The manager’s name. RO Y Text.
6 Recipe Executor
This section describes the basic concepts for the recipe executor and the execution recipe that it stores.
The recipe executor is the component of an executing agent that reads and comprehends the contents of a recipe (its
body) and puts into effect its instructions, settings, and/or other data. The object model of the recipe executor is
shown in Figure 6.1.
Figure 6.1
Recipe Executor
The recipe executor is able to temporarily store recipes for execution purposes, and it may also be able to store
execution recipes for later execution.
The execution process is beyond the scope of RMS.
6.1 Motivations — Specification of the recipe executor and the execution recipe that it stores is necessary to
complete the management of recipes in the factory. The recipe executor provides limited storage for recipes and
minimum capability to manage them. The storage provided is intended to be temporary only.
Some recipe executors have the ability to purposefully change a recipe's body or create new recipes. To ensure that
execution recipes remain synchronized with the managed recipes in a recipe namespace, additional rules are
required for such cases.
The requirements for RMS that are addressed by the recipe executor include the following:
• The ability to create, edit, and change recipes outside the executing agents that execute them,
• The ability for executing agents to use recipes developed externally,
• The ability to share recipes among equipment of the same type,
• Protection of stored execution recipes and of currently selected recipes from unexpected or unauthorized
change,