semi合集-English.pdf - 第1747页
SEMI E42-0704 © SEMI 1995, 2004 16 Because the managed recipe may be applied to multiple agents , it may have multiple agent-specific datas ets . When a recipe is d ownloaded from a recipe namespace to a recipe executor …
SEMI E42-0704 © SEMI 1995, 2004 15
• support for sorting by factory approval and
certification levels,
• the ability to tune a generic recipe for a specific
installation of agent as well as the same agent over
time, and
• the ability to share recipes across executing agents
supporting the same recipe syntax or language(s).
3.2 Basic Concepts — There are two types of recipes
addressed by RMS, the managed recipe that is stored
in a recipe namespace and the execution recipe that is
stored in recipe execution storage. This section
describes the basic concepts concerning both types of
recipes.
3.2.1 Types of Recipes — There are three types of
recipe objects shown in Figure 3.1. Most of Recipe
Management is concerned with the management of
recipes stored in a recipe namespace. These recipes are
called managed recipes. Recipes are also stored by the
recipe executor in the recipe execution storage, and
these are called execution recipes.
Figure 3.1
Recipe Types
The recipe supertype is an abstract type that shows the
common elements and attributes of the managed recipe
and the execution recipe and their differences. The
recipe supertype is not itself intended to be
implemented. That is, recipe object types formally
defined in RMS are either managed recipes or
execution recipes. As indicated by the light lines, the
supertype is not a standardized object.
3.2.2 Recipe Structure — Both the managed and the
execution recipe have a body
4
and a set of attributes.
The body (contents) of the recipe contains the data used
by the recipe executor for its execution process. The
body is also not a standardized object and may not be
accessed through Object Services.
Figure 3.2 illustrates all of the attributes defined by
RMS that are common to both the managed recipe and
the execution recipe. Not all of these attributes are
required for a minimum implementation of RMS. The
rules for setting the values of certain attributes,
however, are different for the managed recipe and the
execution recipe.
Figure 3.2
Recipe Supertype
The identification attributes, those attributes used for
purposes of identification, are discussed in Section 3.3.
The other attributes are discussed in later sections
specific to each recipe type.
The managed recipe also may maintain a set of
attributes that are specific to a single executing agent.
The agent-specific attributes are technically attributes
of the association between the recipe and the executing
agent. In RMS, however, these attributes are treated as
attributes of a component of the recipe called the agent-
specific dataset, in order to allow them to be managed
within the namespace along with the other attributes of
the recipe. Agent-specific attributes allow the recipe to
be personalized for particular executing agents (i.e.,
particular recipe executors).
4 The recipe’s body corresponds to a “process program” in SEMI E5
and SEMI E30.
SEMI E42-0704 © SEMI 1995, 2004 16
Because the managed recipe may be applied to multiple
agents, it may have multiple agent-specific datasets.
When a recipe is downloaded from a recipe namespace
to a recipe executor, the managed recipe is transformed
into an execution recipe by taking the agent-specific
attributes of the agent-specific dataset for that agent (its
recipe executor) and merging them into the attributes of
the execution recipe.
Methods of storing a recipe or the components of a
recipe are not dictated by RMS. However, the
association between a recipe's body and its attributes
shall be carefully maintained.
3.2.2.1 Recipe Body — The recipe body contains the
reusable instructions, settings, parameters, and other
data that the recipe executor reads to execute the recipe
and control its operation.
A recipe body may be in one of two basic forms:
source (text) or object. The purpose of the source form
is to encourage the use of human-readable and human-
editable text. The object form supports the types
intended only to be read and applied by machines and
other automated systems, such as those produced by
vision systems or CAD programs, as well as proprietary
formats created and used by the recipe executor.
3.2.2.1.1 Source Form — Recipes that are created and
modified by a form of editor should be available in
source form. The source form of a recipe body is
equivalent to a text file, such as ASCII or JIS-8, that
can be created, read, printed, or modified with any
"standard" text editor
5
. The executing agent is not
required to supply such a text editor, but its recipe
executor should be able both to read and write recipes
in source form. Editing is not covered by RMS.
The source form of a recipe may be copied from one
namespace to another namespace and from a
namespace to a recipe executor's recipe execution
storage, and all recipe executors with access to a given
namespace are assumed to use the same recipe
language and the same functionality.
Two restrictions are placed on the interpretation of the
text transferred between agents:
• In ASCII, the valid characters are from space
(20
16
) through "~" (7D
16
), plus the tab (09
16
),
linefeed (0A
16
), carriage return (0D
16
), and form
feed (0C
16
) characters. The space and tab are
5 The intent is not to specify the text editor, but rather to allow a user
to modify text on the basis of clear guidelines and restrictions that
may apply. Source form recipes are highly desirable to reduce the
proliferation of, and need for, proprietary editors that are dedicated
and language-specific.
considered as horizontal whitespace characters,
and the carriage return and form feed characters
are considered vertical whitespace characters. The
line-feed character is used to define the end of a
line of text (eol).
• The meaning of a recipe should not depend on
embedded control characters, or specific
whitespace characters, or the existence of
whitespace at the end of a line. Horizontal
whitespace characters should be treated alike for
purposes of interpretation, as should vertical
whitespace characters. All other characters, aside
from those specified here, are discouraged and, if
found, should be removed from the text prior to
transfer.
In general, the recipe language and syntax used within a
recipe body are beyond the scope of recipe
management. However, to reduce arbitrary variability
for the user, the following "rules" are recommended:
• Case is not significant for the purpose of
comparison or meaning but should be retained as
encountered, since it is often used to enhance
readability. For example, the tokens alarmlevel,
ALARMLEVEL, and AlarmLevel should all have
the same meaning.
• Comments may be included in the text and are
ignored in recipe interpretation. Two types of
comments are defined: comments that begin with
the character pair "//" continue to the end of the
line, while comments that begin with the character
pair "/*" are terminated only by the character pair
"*/". A comment of the second type is terminated
by the first character pair "*/" that follows.
Comments may not be nested. Nested comments
are not honored and may generate a syntax error.
• The minimum line consists of a single line-feed
character.
In addition, recipe languages that support external
references to other recipes should use the text form
defined for the recipe identifier (Section 3.2.3.4) and
for the recipe specifier (Section 3.2.4.1.2).
The supplier of the recipe executor shall provide
documentation that formally defines each recipe
language that the agent supports. Two forms are
required, one for the user, who must be able to write
correct recipes, and one that covers both the syntactical
and lexical structures of the language using a formal
descriptive protocol such as the Backus-Naur Form
(BNF). The second form of documentation allows
parsers to be built that are capable of pre-checking a
recipe for syntactic and lexical correctness prior to
downloading it. Pre-checking improves efficiency and
SEMI E42-0704 © SEMI 1995, 2004 17
performance by reducing the demand for recipe
checking by the recipe executor.
The final responsibility for determining the correctness
of a recipe shall belong to the recipe executor.
3.2.2.1.2 Object Form — Recipes that cannot be
translated into a meaningful source form include
datasets derived from vision systems or mechanical
systems through a special hardware-dependent "teach"
operation. Such recipes may remain in a proprietary
object form and may or may not be applicable to other
recipe executors because of their hardware
dependencies.
For greater efficiency, recipe executors may rewrite
(e.g., tokenize) a source recipe to generate a
proprietary object form of the recipe. This is called the
derived object form, to distinguish it from object form
recipes that never exist in source form. The agent's
manufacturer may choose to make this form available
for transfer as well. From the point of view of the
supervisor, the body of a recipe that is in object form is
an unstructured binary vector or string. In general, it
cannot be edited on a supervisor, and the source form
of the recipe is still required. Derived object form
recipes that cannot be used by multiple recipe executors
should not be stored in recipe namespaces that are
shared.
Where both the source form and the derived object form
exist, the identifier for the object form of the recipe
shall be different from that of the source form in some
recognizable way. The supplier of the recipe executor
shall provide a documented method for distinguishing
one from the other within the identifier. This method
must be such that the relationship of the derived object
form recipe from the original source recipe is obvious
to the user. (See Section 3.2.3.4 for examples.) An
attribute of the recipe, SrcRcpID, is provided to retain
the relationship between the source form recipe and the
derived object form recipe.
3.2.3 Recipe Identification — The ability to properly
and unambiguously identify a recipe is critical to both
recipe management and processing. It is also important
for the user that identification be logical. RMS defines
three elements used to uniquely identify a recipe within
any recipe namespace. These three elements are the
recipe's class, name, and version. Each element is
expressed as a text string, and they are concatenated
together to form the recipe identifier (see Section
3.2.3.4).
3.2.3.1 Recipe Name — The recipe name is a user-
defined text string that may be used to encode the
technology, layer, manufacturing area, and other
characteristics. The recipe name alone is not necessarily
unique within either a given class or a given
namespace.
The recipe name is subject to the conventions for text
as defined in Section 1.5.1.
3.2.3.2 Recipe Class — A recipe class is a formal
grouping of recipes that have a common syntax. A class
may contain subclasses where the recipes within the
subclasses operate in different environments or have
different syntaxes from the parent class and/or from one
another. A subclass is itself a class and may contain
further subclasses.
The overall model for recipes is a set of class
hierarchies or "class trees" defined by the supplier of
the recipe executor. The major classes of recipes are the
PROCESS class, the SERVICE class, and possibly
other agent-specific classes. These are called primary
classes. A primary class is a class that is not a subclass
of another class.
The PROCESS class is a required primary class and is
composed of recipes whose primary purpose is to
increase the manufactured value of the production
material
6
.
The SERVICE class is an optional primary class used
for recipes whose purpose is to maintain, prepare,
calibrate, or test the operation of equipment. Typical
subclasses of the SERVICE class might be
CALIBRATION and CLEANING. SERVICE recipes
that use the same recipe language as normal process
recipes are not required to be placed into a separate
primary class. The SERVICE class allows separation
and use of a different syntax for special non-process
purposes.
Other primary classes that do not fit the PROCESS or
SERVICE may be provided by the supplier of the
recipe executor. Such additional classes, and their
function, shall be documented.
Recipes that are not in the PROCESS class or one of its
subclasses shall not be used for production purposes.
However, recipes within the PROCESS class may be
used for purposes other than production.
Figures 3.3 and 3.4 show examples of object models of
possible classes and subclasses for a wire-bonder and
for a furnace with an automatic boat-loader subsystem.
6 Material handling systems, wafer metrology, wafer measurement,
wafer inspection systems, as well as process equipment which
directly changes the characteristics of the material, increase the value
of the material in some way.