semi合集-English.pdf - 第1778页

SEMI E42-0704 © SEMI 1995, 2004 47 7 Agents This section describes the agent and resources as they are used in Recipe Managem ent. The concept of agent is introduced t o cover the different t ypes of RMS implem entations…

SEMI E42-0704 © SEMI 1995, 2004 46

6.6.4 Last Value — Some recipe executors may also

want to save the last value set by the user for each

variable parameter and use it as the new initial value of

that parameter when the same recipe is rerun.

This is useful when internal conditions drift in a

consistent manner over time, the parameters are

occasionally modified to compensate for such drift, and

the last setting used is, therefore, a better “default” than

the one specified in the recipe itself.

Permission to save the last value may be expressly

granted by the user in the recipe attribute ExecChgCtrl

Care should be taken to prevent unintentional

modifications.

6.7 Production — Equipment utilizations states are

defined by SEMI E10 (Standard for Definition and

Measurement of Equipment Reliability, Availability,

and Maintainability (RAM)). These states include the

PRODUCTIVE and STANDBY states used by the

factory for normal production work. The attributes

ProdApprove

and ProdCertify are defined as required

only for equipment supporting states defined in this

document.

To ensure that only recipes authorized for production

are executed while the executing agent is in the

PRODUCTIVE state, or are selected while in the

STANDBY state, the authorized user may set the

values of the attributes ProdApprove

and/or ProdCertify

to non-zero values. Non-zero values in ProdApprove

ProdCertify

represent minimums for a recipe's

ApprovalLevel

and Certified attributes, respectively.

The recipe executor is responsible for comparing the

corresponding recipe attributes ApprovalLevel

and

Certified

. When a recipe is selected for execution

(implicitly or explicitly) while either of the

PRODUCTIVE or STANDBY states is active, the

value of ApprovalLevel

is required to be equal to or

greater than the value in ProdApprove

, and the value in

Certified

is required to be equal to or greater than the

value in ProdCertify

. Otherwise, the select shall fail.

6.8 Recipe Executor Attributes — The recipe executor

is owned by the agent that provides a recipe execution

resource. The recipe executor in turn owns the recipes

that it has stored. It shall support Object Services for its

owned object types and for itself.

Table 6.2 defines the attributes of the recipe executor in

alphabetical order.

Table 6.2 Recipe Executor Attribute Definition

Attribute Name Definition Access Rqmt Form

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

ObjID Text. RO Y Text.

DefaultNamespace The name of an executing agent’s namespace

used for all hardware-dependent and other

agent-specific recipes.

RW Y Text.

ProdApprove The minimum value of a recipe’s approval

level accepted during productive and standby

states. Required for SEMI E10 support only.

RW N Unsigned integer.

ProdCertify The minimum value of a recipe’s certification

level accepted during productive and standby

states. Required for SEMI E10 support only.

RW N Unsigned integer.

RunCycleUnit The process unit on which the calculation of the

estimated value of the recipe generic attribute

EstRunTime is based.

RO N Case-sensitive formatted text

composed of a unit of

measure and an optional

numeric suffix. Compliant

with SEMI E5, Section 9.

RecipeSelectID A list of recipe identifiers for the currently

selected recipes.

RO Y List of formatted text.

RecipeSelect-

Parameters

A list of all parameter definitions in effect for

the i

recipe identifier in RecipeSelectID. The

maximum value for i is determined by the

equipment supplier as the maximum number of

recipes which may be selected at the same time.

Required if variable parameters are supported.

RO N List of structures composed

of parameter name, parameter

value, parameter restriction.

SEMI E42-0704 © SEMI 1995, 2004 47

7 Agents

This section describes the agent and resources as they are used in Recipe Management. The concept of agent is

introduced to cover the different types of RMS implementations and to provide a context for the other specific

object types introduced in RMS.

7.1 Definitions — A resource is an owned entity that has an active role in factory operations. A factory has many

different kinds of resources. Some resources, such as valves, may be primarily physical. A software application is a

type of resource not generally considered as physical. The factory itself is a resource for the corporation.

An agent is a system in a factory — a type of resource that includes both hardware and software components, at

least some of which are also resources. Intelligent equipment that provides recipe namespace capability, for

example, would be an agent with a recipe namespace resource, as well as a computer platform, operating system,

and electro-mechanical components, some or all of which represent other types of resources. An agent may be a

component of another agent, and it may also contain other agents as components. For example, a cluster module is a

component of a cluster and may itself contain intelligent subsystems as components.

Agents may, in some cases, share certain resources with other agents. An example is a docking station that connects

two clusters.

Services defined by RMS may be provided at various levels within the factory. The generic term agent may be

applied at any of these levels as appropriate. Typical agents that use and provide Recipe Management services

include equipment, clusters, cluster modules, cells, and independent recipe namespace servers

. The term agent

applies equally well to each of these.

A service resource is a set of services within a particular area of specialization. Service resources of interest to

RMS are the recipe namespace resource, the recipe execution resource, and the Object Services Resource. The

service resource object, illustrated in Figure 7.1, allows a group of message services defined by a service standard

(such as RMS) to be represented by a single object, one of the subtypes of the service resource. However, this

concept is introduced for clarification only. The service resource object is not a standardized object.

Figure 7.1

Examples of Service Resource Subtypes

An agent is introduced as a standardized object that provides one or more service resources. Figure 7.1 shows an

example of an agent composed of different service resources. Also, an agent may supervise subordinate agents or

be supervised by a superior agent, each of which in turn will possess their own service resources.

9 A recipe namespace server is an agent whose primary function is to provide recipe namespace capabilities.

SEMI E42-0704 © SEMI 1995, 2004 48

Agents interact with one another collaboratively and/or

hierarchically, through the service resources that they

provide, to perform work in the factory.

7.2 RMS Resources — The service resources defined

by RMS are the recipe namespace resource and the

recipe execution resource.

A recipe namespace resource consists of the set of

message services defined in Section 12, corresponding

to the namespace operations defined in Sections 8 and

9. All services required for operations designated as

required are fundamental and shall be provided for an

RMS-compliant recipe namespace resource.

A recipe execution resource consists of the set of

messages defined in Section 14 corresponding to the

recipe executor operations defined in Section 11. All

services required for operations designated as required

are fundamental and shall be provided for an RMS-

compliant recipe execution resource.

7.3 Agent Attributes — Table 7.1 defines the public

attributes of agents that are required for recipe

management.

Table 7.1 Agent Attribute Definition

Attribute

Name

Definition

Access

Reqt

Form

ObjType Agent object

type.

RO Y Text:

“Agent”

ObjID The agent's

name, assigned

by an

authorized

user.

RO Y Text.

8 Recipe Management Operations

There are two important kinds of operations involving

recipes within a namespace. Those that change a

recipe's attributes or body are called recipe

management operations. Those that affect the set of

recipe identifiers within a namespace are part of recipe

namespace management operations. A few operations

qualify as both recipe management and namespace

management and are discussed in their different aspects

under both topics.

A third type of operation is informational only and

requires reading but not changing recipe attributes.

Operations of this type that require knowledge of the

attributes of the namespace or of more than one recipe

are discussed in Section 9.

This section describes recipe management operations.

Requests for recipe operations are always directed to

the namespace where the recipe is stored. Recipe

management operations are delegated by the namespace

manager to the namespace segment, which is

considered as the recipe manager. This is invisible for

a centralized namespace and explicit for a distributed

recipe namespace.

Operations may be invoked by the operator or through

namespace services defined in Section 12. In many

cases, service scenarios consist of a single message

request from the service user and a corresponding

response from the namespace manager. This case is

illustrated in Section 12.2, Figure 12.1. Operations

requiring additional messages are discussed in Section

8.2.

The service user is responsible for proper authorization

of the user prior to requesting an operation that is

restricted to authorized users

through RMS services.

8.1 Recipe Lifecycle — A typical production recipe

goes through various stages in its development within a

namespace. These stages are shown below in a typical

order through their associated operations. The attributes

concerning the body are provided by the initiator of the

operation.

create — The create operation enters a recipe body

into the namespace.

Editing is expected, but not required, to be performed

outside the namespace. Where provided by the

manager, the same requirements concerning creating or

updating a recipe are to be followed.

update — A recipe is updated when a body (typically,

a modification of the original body) is entered into the

namespace to replace the body of an existing recipe that

is not write-protected. The attributes concerning the

body are provided by the initiator of the operation.

verify — The verify operation is used to build a recipe.

Checks for semantic correctness may also be performed

at this time but are not required. The recipe body is read

and checked for syntactical correctness, and all external

references and variable parameter definitions are

collected. The verification operation may be delegated

to a recipe executor, which returns the required

information.

write-protect — At some point during its development,

an authorized user needs to be able to prevent the

accidental deletion or modification of a recipe and

requests to have it be write-protected. A write-

protected (read-only) recipe may not be updated,

renamed, deleted, unlinked, or relinked.

link — The link operation is used to signify that the

recipe is ready for execution. If the recipe has external

references, linking also builds a linked recipe set by

collecting the external references and variable

parameter definitions and saving them for quick access