semi合集-English.pdf - 第1770页

SEMI E42-0704 © SEMI 1995, 2004 39 5.11.4 Distributed Recipe Namespace Manager Attribute Definition — Table 5. 5 defines t h e attribut es required for a distributed re cipe namespace manager . Table 5.5 Distributed Reci…

100%1 / 7923
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,
SEMI E42-0704 © SEMI 1995, 2004 40
• Execution of recipes without errors, including
errors detected during verification and validation
errors caused by improper settings or parameters
or incompatibility with the current configuration,
• The ability to change a recipe's parameters
between runs in a systematic way without changing
the recipe itself,
• The ability to dynamically connect and disconnect
the executing agent from the communications
environment, and
• The ability of standalone equipment to execute
recipes without a communications link.
6.2 Description — The recipe executor is able to
receive a downloaded execution recipe and temporarily
store it. The executor can verify the recipe body
(Section 11.2.2) both at the time of the download and
after the recipe has been stored. It is able to store at
least as many recipes as it requires for a single process
cycle, which is determined by its own requirements.
Recipes stored by the recipe executor may be
downloaded from more than one namespace. To
prevent ambiguity or conflict between recipe identifiers
from different namespaces, the name of the namespace
from which the recipe was originally downloaded is
retained in the identifier of the execution recipe.
The recipe executor selects one or more specified
recipes by validating them and preparing them for
execution. This may include moving the recipes into a
separate recipe execution area to create an executable
copy recipe. The executable copy recipe, if it exists
separately, shall be protected from inadvertent change
caused by other activities, such as downloading a new
recipe. The executable copy recipe is not otherwise
addressed by RMS. If a separate copy is selected, the
stored execution recipe shall be protected from change.
Protection from change and permission to change are
discussed in Section 6.6.
Validation of a recipe consists of checking the values of
its settings and variable parameters against existing
supplier-defined and/or user-defined restrictions, and
ensuring the recipe, or the linked recipe set, is valid for
the current configuration of the executor (e.g.
equipment or attached module).
Additionally, the recipe executor is able to calculate the
amount of available storage, to delete recipes from its
storage to make room for new recipes, to de-select
recipes by preventing them from being re-executed
without another explicit select, to rename an execution
recipe, and to provide requested information about
itself and its stored execution recipes, in conformance
with OSS.
8
The recipe executor may wish to rewrite source form
recipes into a proprietary derived object form that is
more efficient for execution or storage purposes. Where
this type of recipe is to be stored for re-use, a new
identifier is required for the object form, as described in
Section 3.2.2.1.2. Derived object form recipes are
discussed in detail in Section 11.2.2.1.
6.3 The Execution Recipe — An execution recipe is a
type of recipe, as shown in Section 3, Figure 3.5. The
recipe executor stores recipes as execution recipes.
Execution recipes are created in one of two ways: they
are either downloaded from a recipe namespace, or
they are created by the recipe executor.
6.3.1 Comparison of Managed and Execution Recipes
— An execution recipe differs from a managed recipe
in two ways: its attributes and its lack of agent-specific
datasets.
The differences in attributes between a managed recipe
and an execution recipe consist of:
• The addition of Namespace
as an identification
attribute of the execution recipe,
• The intermediate parameters, ExtRef
and
Parameters
, of a verified managed recipe, required
for the namespace link operation, are not used by
the recipe executor and are not retained in the
execution recipe,
• The attributes LinkParam
and AgentSpec
LinkParam of the managed recipe are merged into
the single attribute ExecLinkParam
,
• The attributes of the remaining agent-specific
dataset are absorbed into the attributes of the
execution recipe, and
• The addition of the attribute length ExecAttrLength
and attribute timestamp ExecAttrChgTime
attributes, and
• The additional attribute ChangedBody
, which is
required for execution recipes where the recipe
executor is capable of changing the recipe body or
of creating new recipes and is not otherwise used.
The conversion of a managed recipe to and from an
execution recipe is the responsibility of the namespace
manager and is discussed in Sections 9.4.8 and 9.4.9.
Most of these differences are invisible for an unverified
recipe or minimal recipe implementations. For an
8 SEMI E39 (Object Services Standard)