semi合集-English.pdf - 第1743页

SEMI E42-0704 © SEMI 1995, 2004 12 1.7 Docume nt Structure — Figure 1.1 depicts the dom ain of the Recipe Management Standa rd as consisting of Purpose, Conc epts, Behavior, and Me ssage Services. T h is also re flects a…

100%1 / 7923
SEMI E42-0704 © SEMI 1995, 2004 11
Table 1.1 Requirements
Functional Areas Issue Requirements
Management of Recipes Identification Uniquely store, identify, and select recipes in a system.
Easy and clear identification of a recipe.
Multiple Access Share recipes among equipment.
Enable synchronized change of shared recipes among equipment.
History and Traceability Capture the history of recipe usage.
Capture the history of recipe changes.
Life Cycle Management Manage approval of recipes for process development and production.
Operations Protection Protect recipes from unexpected changes.
Protect recipes from mistakes in operations.
Portability Create, edit, and change recipes outside the equipment which execute
them.
Reusability Change recipes for a specific piece of equipment.
Use recipes developed on one piece of equipment for other equipment.
Share recipes among the same kind of equipment by adjusting for
individual differences.
Execution Safety Do not execute recipes that are not syntactically correct.
Execute the specified (selected) recipes without errors.
Protect recipes being executed from inadvertent change caused by other
activities.
Flexibility Change a recipe's parameters during or between runs in a systematic
way.
System Operation System Node Operation Dynamically connect and disconnect equipment to/from the
communications network.
Stand-Alone Operation Execute recipes with no communications link.
Create and change recipes with no communications link.
Manage recipes moved between equipment or from off-line storage
through removable media.
Enable smooth integration of stand-alone equipment into on-line factory
systems.
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
3
, 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.