semi合集-English.pdf - 第1744页

SEMI E42-0704 © SEMI 1995, 2004 13 2.2 Major Objects in RMS — Recipe Management is concern ed with the major areas of functionality illu strated in Figure 2.1: re cipes 3 , recipe namespaces providing persist ent recipe …

SEMI E42-0704 © SEMI 1995, 2004 12

1.7 Document Structure — Figure 1.1 depicts the domain of the Recipe Management Standard as consisting of

Purpose, Concepts, Behavior, and Message Services. This also reflects an underlying structure of the document.

Figure 1.1

Recipe Management Domain

Purpose

provides the motivation for Recipe

Management capabilities and is addressed in Section

1.6. Concepts

provide a detailed introduction to the

standardized objects of RMS, their attributes, and their

relationships with other objects. Behavior

describes the

operations that are performed by, or on, these objects.

Finally, message services

define the messages and their

parameters independently of the protocol in which they

are implemented. Both concepts and behavior represent

an "inside view" of an RMS application, while services

provide an interface from an external view.

• Section 1: the formal introduction to RMS.

• Section 2: an overview of the major objects of RMS

and their relationships, to provide a general

context for the technical detail that follows.

• Sections 3-6: concepts for recipes, recipe

namespace, distributed recipe namespace, and

recipe executor.

• Section 7: the concept of the agent and of service

resources, to provide a more complete context for

RMS implementations.

• Sections 8-11: behavior (operations) for recipe

management, namespace management, distributed

recipe namespace management, and the recipe

executor.

• Sections 12-14: definitions of message services for

the recipe namespace, distributed recipe

namespace, and recipe executor service resources.

• Section 15: RMS compliance.

• Section 16: a glossary of terms, provided as a

convenient reference.

• Related Information: provides background

information on the requirements behind RMS and

examples of applications.

1.8 Applicable Documents

ISO/TR 8509:1987, Information Processing Systems,

Open Systems Interconnection — Service Conventions.

2 Overview of RMS

This section provides an introduction to, and overview

of, the major objects of RMS.

2.1 Recipe Management Models — To provide a

clearer understanding of the major entities or areas of

functionality specified by RMS, they are portrayed as

objects in RMS models, using OMT notation.

Relationship lines in the object-based models do not

represent a direct communication link between objects,

but rather the knowledge and association that one object

has with respect to another.

The models do not indicate the relative location of two

objects.

SEMI E42-0704 © SEMI 1995, 2004 13

2.2 Major Objects in RMS — Recipe Management is concerned with the major areas of functionality illustrated in

Figure 2.1: recipes

, recipe namespaces providing persistent recipe storage, recipe namespace managers that

provide management of the namespace and access to its recipes, and the recipe executor that executes recipes.

Figure 2.1

Major Objects of RMS

3 The recipe object in Figure 2.1 is not itself a standardized object. However, two recipe subtypes defined in Section 3 are standardized objects.

2.2.1 Recipes — Recipes provide a flexible,

manipulatable, and re-usable form for users to select

sequencing and settings to effect a particular result.

Equipment uses recipes in a variety of ways to control

the processing environment, sometimes using several

types of recipes together. Recipes may also be used for

maintenance activities, such as calibration or cleaning.

Recipes can be modified and copied from one

environment to another. Their inherent flexibility as a

form also becomes an endless source of problems

unless they can be managed. Misprocessing,

unintentionally running the wrong recipe for a given

product, is prohibitively expensive for factories.

RMS defines a recipe as an object with attributes —

information about the recipe — as well as content. It is

the attributes of the recipe that allow true management

of recipes, throughout their lifecycles, to occur.

2.2.2 Recipe Namespace — A recipe namespace in

RMS is analogous to a smart file directory. The

namespace provides long-term recipe storage

capability.

Basic operations are part of the namespace

specification. For example, recipes can be copied from

one namespace to another, copied within a namespace,

renamed, created, updated, and deleted. They can be

downloaded to, and uploaded from, an application

called a recipe executor. Several recipes can be linked

together to form a set.

The namespace also can serve as a recipe pool that can

be shared by a group of equipment of a common type.

The distributed recipe namespace is a namespace able

to utilize and manage recipe storage provided by such

an equipment group.

2.2.3 Recipe Namespace Manager — The recipe

namespace itself is passive, a container for recipes. The

recipe namespace manager (manager) provides the

dynamic element that manages the namespace. The

manager represents the interface for the namespace to

the external world and the internal decision authority

within the namespace.

2.2.4 Recipe Executor — The recipe executor (executor) is the component of an agent that understands the

contents of a recipe and is able to verify their syntactical correctness and to validate that it can be executed under

the current configuration. It executes a recipe by reading its contents and applying them appropriately in order to

achieve a desired result.

The recipe executor also may provide additional limited storage capability, but it is restricted from modifying

existing recipes, except under special conditions, to prevent unexpected and/or unwanted change.

2.3 Agent — As used in RMS, an agent is a system, or subsystem, in a factory, that has a physical aspect. It consists

of one or more applications that provide and/or use service resources, such as a recipe namespace manager and/or a

recipe executor, as illustrated in Figure 2.2.

Figure 2.2

An Example of an Agent and Component Applications

Agent is a generalization that covers traditional equipment, supervisory or aggregate systems such as stations, cells,

and clusters, and intelligent subsystems within equipment, such as process modules within a cluster. Other types of

agents may also be implemented, such as those dedicated to recipe namespace management.

An agent that provides a recipe executor is called an executing agent. Equipment is an executing agent with

associated hardware to which the recipe applies and which it uses to do work.

2.4 Implementations — RMS can be implemented on different platforms within a factory. A host controller may

only provide recipe namespace management, while a diskless cluster module may provide only recipe execution.

Traditional equipment capable of operating in stand-alone mode is required to provide a recipe namespace that is

available on powerup as well as a recipe executor component. Additional examples of implementations of RMS are

provided in Related Information 1.

RMS defines the services provided through an external interface. Communications between or within applications

that are internal to an agent are not covered by RMS, so long as the attributes and operations comply with RMS

requirements.

3 Recipes

This section describes the concepts concerning recipes.

3.1 Motivations — Definitions of recipe structure, attributes, and operations address the following issues:

• maintenance of recipe attributes for management and traceability,

• provision of a standard method for transferring attributes separately, as well as with the recipe body,

• reduction or elimination of the need for dedicated recipe editors,

• support for applications requiring multiple recipe types, such as formats or language syntaxes,

• run-to-run control,