semi合集-English.pdf - 第1760页

SEMI E42-0704 © SEMI 1995, 2004 29 Figure 4.1 Recipe Namespace Model All operations performed on a recipe thro ugh Recipe Management services are performed within the namespace by, or under the s upervision of, the names…

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.

SEMI E42-0704 © SEMI 1995, 2004 29

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.

4.4 Member Agents — A namespace that contains

recipes used by multiple agents is called shared.

Otherwise, it is called dedicated or non-shared. Figure

4.2 illustrates two dedicated namespaces, one provided

by an etcher and one by its host. This terminology is

introduced for clarification and descriptive purposes

only.

Figure 4.2

Host Backup of Equipment Namespace

The Members

attribute of the namespace contains the

names (object identifiers) of the agents that use the

recipes in the namespace, and these agents are called

member agents (members) of the namespace. The

namespace manager uses this information as it may

require assistance from a member agent to verify a

recipe.

If the Members

attribute of the namespace contains

multiple agent names, then the namespace is shared.

Otherwise, it may be non-shared or not yet completely

set up. If it is empty (null), the namespace has not been

completely set up and is not fully functional, as certain

operations, including recipe verification, require it to

have content.

4.5 Illustrations — This section provides illustrations

of several possible configurations of a centralized

namespace.

Figure 4.2 illustrates an etcher that has its own local

namespace and that communicates with its supervisor

over an RS-232 line. The supervisor in this example

maintains a separate namespace, providing backup for

recipes of particular significance.

Figure 4.3 illustrates a supervisor with four diskless

subordinates. In this configuration, the supervisor

provides recipes for all four subordinates from a

centralized namespace.

Figure 4.3

Namespace Provided by Supervisor

Figure 4.4 illustrates four executing agents on a

common network with a supervisory agent and a sixth

agent providing a centralized namespace. Each

executing agent is able to access the namespace

independently of the supervisor.

Figure 4.4

Shared Network Access

Figures 4.3 and 4.4 both represent examples of shared

centralized namespaces.

4.6 Attribute Definition Tables — Table 4.1 defines the

attributes of the recipe namespace.