semi合集-English.pdf - 第1759页

SEMI E42-0704 © SEMI 1995, 2004 28 3.5 Execution Recipes — The type of recipe handl ed by a recipe executor is called an execution recipe . This type of recipe has att r ibutes and a bo dy but does not have an agent-spec…

SEMI E42-0704 © SEMI 1995, 2004 27

Table 3.2 defines the attributes of the agent-specific dataset object.

Table 3.2 Agent-Specific Dataset Object Attribute Definition

Attribute Name Definition Access Rqmt Form

ObjType The object type. RO Y Text = "MRcpASDS"

ObjID The object's identifier. Contains the value in

AgentSpec_Agent

RO Y Text.

AgentSpec_Agent The name of the executing agent to which the other

attributes in the dataset apply. Mandatory.

RO Y Text.

AgentSpec_AttrLength The length of the agent-specific attributes, in bytes.

Mandatory.

RO Y Unsigned integer.

AgentSpec_ChgTime Timestamp of when an agent-specific attribute was last

changed. Mandatory.

RO Y Formatted text.

AgentSpec_Comments Comments specific to the agent entered by the author. RW N Text. Maximum length

is 80 characters.

AgentSpec_LinkParam A list of variable parameter definitions modified from

the list in LinkParam

. Valid only for a linked main

recipe. Parameter name and form may not be changed.

RO N List of Structure

composed parameter

name, value, and

restrictions.

Certified The certification-level for the specific agent, assigned

by an authorized user. Reset when

AgentSpec_LinkParam

is modified. Required for

certification support.

RW N Unsigned integer.

AgentSpec_UD_* Non-standard attribute defined by the supplier or user.

Asterisk indicates the part of the attribute name that is

provided in this definition. Must be preserved exactly

except by the defining entity.

RO N Varies with definition.

Text form is limited to

80 characters.

3.4.2.3 Minimal Managed Recipe — The minimal model for a managed recipe is shown in Figure 3.6. Only

required attributes are supported in this model. This model can only be used for single-part recipes in the dedicated

namespace, such as the default namespace required for stand-alone equipment. There are no agent-specific datasets.

Figure 3.6

Object Model for Minimal Managed Recipe

SEMI E42-0704 © SEMI 1995, 2004 28

3.5 Execution Recipes — The type of recipe handled by

a recipe executor is called an execution recipe. This

type of recipe has attributes and a body but does not

have an agent-specific dataset. Most of the generic

attributes of the managed recipe, and certain of the

agent-specific attributes, are also attributes of the

execution recipe, while in other cases, a generic

attribute and an agent-specific attribute are merged and

placed in a new execution recipe attribute.

A managed recipe is converted to an execution recipe

when the recipe is downloaded to the recipe executor,

and correspondingly, an execution recipe is converted

to a managed recipe when uploaded from the recipe

executor.

The execution recipe is defined in detail in Section 6.3.

4 Recipe Namespace

This section defines the basic conceptual model for the

recipe namespace, a logical domain for recipe storage

and management, within which the identifier of a recipe

is guaranteed to be unique. The model in the current

section is applicable to implementations with

centralized storage. Section 5 defines an extension of

the basic model for a distributed recipe namespace.

In general, the term "namespace" refers to a domain of

unique identifiers. The issue of namespace boundaries

exists for all object types, particularly in a distributed

environment, and is not unique to recipes. However,

within the context of RMS, namespace is used as a

synonym for recipe namespace.

4.1 Motivations — A recipe's identifier may not be

unique across different namespaces or throughout a

factory. (That is, a given identifier may be used by

internally different recipes except within a single

namespace.) A primary role of a namespace is to define

an area within which the uniqueness of any given recipe

identifier may be guaranteed.

The requirements for Recipe Management that are

addressed in this section include:

• to define the boundaries of specific areas where

recipes may be uniquely identified, stored, and

retrieved,

• to define the attributes and operations for the

management domain of recipes, including recipe

protection and recipe operations,

• to allow control of removable media,

• to allow stand-alone equipment to execute recipes,

• to facilitate smooth integration of stand-alone

equipment into on-line factory systems,

• to allow integrated equipment to continue to

execute recipes when communications have been

lost, and

• to provide the basis for the distributed model in

Section 5, which allows a supervisor to use and

manage the storage capacity of its subordinate

agents.

4.2 Namespace Model — The namespace model serves

two major purposes. First, it provides a common set of

management rules. Second, it allows a set of recipes to

be shared among a group of executing agents that have

a common process type, common functionality, and a

common recipe language.

Figure 4.1 shows the basic namespace model with four

objects: the recipe, the namespace itself, a namespace

component called recipe namespace segment, and a

recipe namespace manager.

The recipe namespace manager (or manager)

represents the interface for the namespace to the

external world and the internal decision authority

within the namespace. All services for the namespace

and its recipes are provided by the manager. The

namespace itself is passive. While it has important

attributes, the namespace has no operations, and it

provides no services.

The recipe namespace segment (or segment)

represents both the internal storage element and the

actual manipulation of recipes within the namespace,

under the supervision of the manager. In the basic

model, it also provides no public services. The

relationship between the segment and the manager in

this model is presumed to be internal to an application.

Figure 4.1 represents a namespace with centralized

storage. However, it can easily be extended to the

distributed recipe namespace, which may have

multiple segments, each provided by a different external

agent. For that case, the manager and segment must

provide public services for one another.

Figure 4.1

Recipe Namespace Model

All operations performed on a recipe through Recipe Management services are performed within the namespace by,

or under the supervision of, the namespace manager, with two exceptions. A namespace manager is not required to

understand the syntax of the recipe languages. For this reason, recipe editing (modifying a recipe's body) is not part

of the namespace definition, and verification shall be provided by a recipe executor of an appropriate executing

agent (see Section 6). These two activities require an in-depth understanding of the particular recipe languages used.

Their separation from the other activities allows generic namespace capabilities to be provided.

4.3 Namespace Specifications — The combination of the recipe namespace, its segment component, and its

manager provides storage, retrieval, and management of recipes conforming to RMS.

A namespace manager is responsible for maintaining the integrity of the namespace, the integrity of the recipes

within the namespace, and the integrity of the recipe identifiers. It understands the rules regarding recipes, their

attributes, and their components, and it is responsible for enforcing those rules. It will not allow a read-only recipe

to be changed or deleted, for example. Therefore, it will not accept a recipe with an identifier already used by a

read-only recipe.

A namespace has no restrictions on the read access of a recipe as a whole or of its attributes, nor is it concerned

with the uses to which they might be put outside the namespace. The ability for multiple agents to share the same

recipes is determined solely by the ability of the agents to access the same namespace. Issues of security and

authentication are beyond the scope of RMS.

The term recipe namespace, or namespace, is used inclusively to refer to those attributes, operations, and other

requirements common to both the namespace described in this section and to its distributed subtype. The term

centralized namespace is used in references to an instance (implementation) of the basic model and to clarify

statements that do not apply to instances of the distributed subtype.

A centralized namespace is analogous to a single directory of files, where duplicate file names are not allowed. It

may exist in several different configurations that are incidental to namespace requirements.

It is possible to provide a namespace that uses removable media for its physical storage. Recipes may then be

transferred to and from this namespace to any other namespace.

In no case shall it be possible to transfer recipes into a namespace except according to the requirements for

namespace management. For example, a read-only recipe may not be replaced.

The centralized namespace may be applied several ways. An agent with execution capabilities that may be operated

in stand-alone mode shall provide itself with a centralized namespace to be used when operating in stand-alone

mode. Other agents, such as diskless process modules in a cluster, may expect to rely upon the namespace

capabilities provided by the cluster supervisor.