semi合集-English.pdf - 第1739页
SEMI E42-0704 © SEMI 1995, 2004 8 1.4.2 For m binary — A st ring of bit values (ze roes and one s), with a format that is either left unspecified or specified by bit position, with the most significan t bit first. The to…
SEMI E42-0704 © SEMI 1995, 2004 7
SEMI E42-0704
RECIPE MANAGEMENT STANDARD: CONCEPTS, BEHAVIOR, AND
MESSAGE SERVICES
E
This standard was editorially modified in September 1999 to conform to its non-provisional status. Changes
were made to Section 1.2.
1 Introduction
This standard defines the concepts required for
management of recipes, the operations or behavior
provided by the Recipe Management Standard (RMS),
and the messages through which services are provided
through an interface between the provider and the user
of these services.
1.1 Purpose — The purpose of this standard is twofold:
• To enable applications software to be developed
that can assume the existence of standard concepts,
behaviors, and message services that collectively
form Recipe Management and that take advantage
of them.
• To enable software to be developed to offer the
Recipe Management capabilities.
1.2 Scope — This is a standard that defines concepts,
behavior, and services to support the integration of
automated recipe management within a semiconductor
factory. These services are applicable to a variety of
relationships, including both traditional
host/equipment and cluster tool controller/attached
module communications and control.
The standard provides a set of communications services
which allows such systems to transfer and manage
recipes to ensure the correct processing of material
within semiconductor manufacturing equipment and
systems. RMS also requires compliance to SEMI E39
(Object Services Standard (OSS): Concepts, Behavior,
and Services) for completeness.
This document describes several different hierarchical
relationships: supervisory agents and their supervised
agents, recipes and their subrecipes, and recipe classes
and their subclasses. Such hierarchical relationships
provide a natural organizational and classification
structure that is reflected in many different kinds of
systems, such as telephone switching systems and
directory trees. It is the intent of this standard to support
logical hierarchical relationships rather than to require
that strict hierarchical relationships be implemented in
systems architecture.
RMS places no restriction on where the set of defined
services is implemented.
1.3 Referenced Documents
1.3.1 Semiconductor Equipment and Materials
International (SEMI)
1
1.3.1.1 SEMI Equipment Automation/Hardware
Volume
SEMI E10 — Standard for Definition and Measurement
of Equipment Reliability, Availability, and
Maintainability (RAM)
1.3.1.2 SEMI Equipment Automation/Software 2
Volume
SEMI E30 — Generic Model for Communications and
Control of Manufacturing Equipment (GEM)
SEMI E39 — Object Services Standard: Concepts,
Behavior, and Services
SEMI E53 — Event Reporting
1.3.2 Other References
James Rumbaugh, Michael Blaha, William Premerlani,
Frederick Eddy, William Lorensen, Object-Oriented
Modeling and Design, Englewood Cliffs, New Jersey:
Prentice-Hall, 1991.
D. Harel, Statecharts: A Visual Formalism for Complex
Systems, Science of Computer Programming 8, 1987.
1.4 Definitions — Basic definitions for objects,
services, and form are provided in SEMI E39, Sections
4.1 through 4.4. This section provides additional
definitions.
Definitions in Section 1.4.3 are specific to RMS.
1.4.1 Services
service provider — An application (a component of an
agent) responsible for providing services to the service
user.
service user — (service consumer) An application that
uses the services provided.
1 Semiconductor Equipment and Materials International (SEMI), 805
East Middlefield Road, Mountain View, CA 94043, 650.964.5111,
FAX 650.967.5375
SEMI E42-0704 © SEMI 1995, 2004 8
1.4.2 Form
binary — A string of bit values (zeroes and ones), with
a format that is either left unspecified or specified by bit
position, with the most significant bit first. The total
length of the string is a multiple of eight. Messaging
protocol may impose restrictions on length.
1.4.3 Recipe Management — This section introduces
basic terminology used in RMS. Entries are in
alphabetical order. Additional definitions and
specifications are provided in later sections.
agent — An intelligent system within a factory that
provides one or more service resources and uses the
services of other agents. This is a generalization that
includes host, equipment, cell, cluster, cluster module,
station controller, and work station. Agents are
associated with a physical system or a collection of
physical systems, such as computer platforms.
authorized user — A user who can be identified to an
agent as having the level of authority required for a
particular activity, such as certifying a recipe for that
equipment.
collection event — A detectable occurrence of interest
to a service user.
component agent — A subordinate agent that provides
services to a supervisory agent.
download — An operation that transfers a recipe
(down) to an execution storage area.
edit — An operation which creates a new recipe body
or changes the body of an existing recipe.
editor — A service which allows a user to edit a recipe.
Editors are not specified in RMS.
equipment
2
— An agent with associated hardware that
provides, at a minimum, recipe execution services.
event — A detectable occurrence significant to an
object.
execution (recipe execution) — The process of reading
the recipe contents and implementing its instructions,
process parameters, or other information required for its
own processing.
executing agent — An agent that provides recipe
execution capabilities.
execution area — The storage location of the recipe(s)
currently selected (ready) for execution.
host — A supervisory agent that represents the factory
to its subordinates.
2 The term "equipment" is restricted in RMS to "intelligent
equipment."
logical recipe — A recipe with a particular set of
attributes and a particular body, considered
independently from its physical location. A logical
recipe may have multiple instances or copies.
name — A text-based attribute of an object that may be
used as all or part of its identifier.
namespace — In general, a domain within which object
identifiers are unique. In RMS, the term namespace is
used as a synonym for recipe namespace, unless
otherwise stated.
operator — The user who interacts locally with agent
through the agent's interface.
recipe — The pre-planned and reusable portion of the
set of instructions, settings, and parameters under
control of an agent that determines the processing
environment seen by the manufactured object and that
may be subject to change between runs or processing
cycles.
recipe class — A formal grouping of recipes with a
common language syntax and functionality.
recipe executor — The component of an executing
agent that executes recipes.
recipe namespace — A logical management domain
with the responsibility for the storage and management
of recipes, the ensurance of the uniqueness of recipe
identifiers within that domain, and the provision of
services pertaining to recipes stored within that domain.
recipe parameter — A control value that affects the
agent's process.
select — The act of preparing a recipe for execution.
setting — A static value accessible to the user, through
one or more methods, that is used by equipment to
control its process. Settings include, but are not limited
to, setpoint values. Settings typically may be specified
within a recipe.
storage area — An area where objects and data are
stored.
subordinate agent — An agent that is a component of,
or managed by, another agent.
supervisory agent — An agent with supervisory
responsibilities for one or more subordinate agents.
timestamp — The notation of the date and time of the
occurrence of an event.
upload — An operation that transfers a recipe (up) from
an execution storage area.
user — A person interacting with an agent directly
through the agent's human interface or indirectly
through the agent's supervisor.
SEMI E42-0704 © SEMI 1995, 2004 9
validate — The action of checking recipe contents to
ensure that parameter type
and range are valid for the
equipment configuration prior to execution. [Note that
validation and verification are used in different ways.]
variable parameter — A formally defined variable
(setting) defined in the body of a recipe permitting the
actual value to be supplied externally.
verify — The operation of reading a recipe's contents to
ensure that it is syntactically correct and identifying
elements that must be made public.
version — Part of a recipe's identifier that is used to
show its heritage.
1.5 Conventions — The following conventions are
used in this document:
• To highlight terms specific to RMS (excluding
terms defined in Sections 1.4.1 through 1.4.3 that
are common to multiple standards), a defined term
appears in boldface wherever it first appears and
wherever it is defined. This alerts the reader to
those terms with specific meanings. Except for
terms that are very common, such as recipe, host,
and equipment, defined terms otherwise are in
italics wherever they appear.
• Terms related to objects and object services are in
conformance with SEMI E39 (Object Services
Standard: Concepts, Behavior, and Services). A
brief discussion of objects is provided in the
Appendix of that document.
• Attribute names are underlined
.
• Attributes called "names" in RMS are generally
intended to be used for the ObjID
attribute of a
standardized object.
• To prevent the definition of numerous message
parameters named "XxxList," this document adopts
the convention of referring to the list as "(List of)
Xxx". In this case, the definition of the parameter
Xxx will be given, not of the list. The term "list"
indicates a collection (or set) of zero or more items
of the same data type.
For attributes that are lists, this convention is not
followed, as the entire attribute, as a list, must be
assigned a specific name.
1.5.1 Text String Restrictions — Text strings used in
attribute names, attribute values, or message
parameters, are subject to the restrictions defined by
OSS: Text in ASCII is restricted to the characters
between 20
16
and 7D
16
, excluding the question mark "?"
(3F
16
), the asterisk "*" (2A
16
), and the tilde "~" (7E
16
).
Text strings used as, or within, the object identifier
ObjID
are additionally restricted to exclude the "greater
than" symbol ">" (2E
16
) and the colon character ":"
(3A
16
) to conform with OSS requirements.
1.5.2 Harel State Model — This document uses the
Harel State Chart notation to describe the dynamic
behavior of the objects defined. An overview of this
notation is presented in an Appendix of SEMI E30. The
formal definition of this notation is presented in Science
of Computer Programming 8, "Statecharts: A Visual
Formalism for Complex Systems," by D. Harel, 1987.
This document also adopts the extension of Harel
notation to show the deletion of an object as used by
Rumbaugh, et al. (see Section 1.5.2.1).
1.5.3 Objects — Standardized objects defined by RMS
conform to the requirements of SEMI E39 (Object
Services Standard: Concepts, Behavior, and Services).
RMS adopts the convention of showing standardized
objects as drawn with a heavy line in object models.
Non-standardized objects are used to illustrate concepts
and relationships but are not formally defined and
cannot be accessed through Object Services. A list of
standardized objects defined by RMS is included in
Related Information 1.
1.5.3.1 OMT Object Information Model — The object
models are presented using the Object Modeling
Technique, developed by Rumbaugh et al., in Object-
Oriented Modeling and Design, Prentice-Hall,
Englewood Cliffs, NJ, 1991. Overviews of this notation
are provided in an appendix of SEMI E39 (Object
Services Standard: Concepts, Behavior, and Services).
1.5.3.2 Object Attribute Representation — The object
information models for standardized objects will be
supported by an attribute definition table with the
following column headings:
Attribute
Name
Definition Access Rqmt Form
The formal
text name of
the attribute.
Description of the
information
contained.
RO or
RW
Y or N (see
below)
The Access column uses RO (Read Only) or RW (Read
and Write) to indicate the access that users of the
service have to the attribute.
A 'Y' or 'N' in the Requirement (Rqmt) column
indicates if this attribute must be supported in order to
meet fundamental compliance for the service.
The Form column is used to indicate the format of the
attribute. (See Section 1.4 for definitions.)