semi合集-English.pdf - 第1746页

SEMI E42-0704 © SEMI 1995, 2004 15 • suppo rt for sorting by factory approval and certification levels , • the ab ility to tune a generic recipe for a specific installation o f agent as well as the same agent over time, …

100%1 / 7923
SEMI E42-0704 © SEMI 1995, 2004 14
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,
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