semi合集-English.pdf - 第1740页
SEMI E42-0704 © SEMI 1995, 2004 9 validate — The action of checki ng recipe contents to ensure that param eter type and range are valid for the equipment configuratio n prior to executio n. [Note t hat validation and ver…
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.)
SEMI E42-0704 © SEMI 1995, 2004 10
1.5.4 Service Message Representation
Service Resource Definition
A service definition table defines the specific set of
messages for a given service resource, as shown in the
following table:
Message Service Name Type Description
Message name N or R The intent of the service.
Type can be either N = Notification or R = Request.
Notification type messages are initiated by the service
provider, and the provider does not expect to get a
response from the user.
Request messages are initiated by a service user.
Request messages ask for data or an activity from the
provider. Request messages expect a specific response
message (no presumption on the message content).
Service Parameter Dictionary
A service parameter dictionary table defines the
parameters for one or more services, as shown in the
following table:
Parameter Form Description
Parameter X Data type A parameter called X is B in
A.
A row is provided in the table for each parameter of the
service. The first column contains the name of the
parameter. This is followed by columns describing the
form and contents of the corresponding primitive.
The Form column is used to indicate the type of data
contained in a parameter. (See Section 1.4 for
definitions.)
The Description column in the Service Parameter
Dictionary table describes the meaning of the
parameter, the values it can take on, and any
interrelationships with other parameters.
To prevent the definition of numerous parameters
named "XxxList", this document adopts the convention
of referring to the list as "(List of)Xxx". In this case, the
definition of the variable 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. Where a list
is used in both the request and the response, the list
order in the request is retained in the response. A list
must contain at least one element, unless zero elements
are specifically allowed.
Service Message Definition
A service message definition table defines the
parameters used in a service, as shown in the following
table:
Parameter Req/Ind Rsp/Conf Description
Parameter X (see
below)
(see
below)
A description of the
service.
The columns labeled Req/Ind and Rsp/Conf link the
parameters to the direction of the message. The
message sent by the initiator is called the "Request".
When receiver terms this message the "Indication" or
the "Request", the receiver may then send a
"Response", which the original sender terms the
"Confirmation".
The following codes appear in the Req/Ind and
Rsp/Conf columns and are used in the definition of the
parameters (e.g., how each parameter is used in each
direction):
"M" — Mandatory parameter — must be given a
valid value.
"C" — Conditional parameter — may be defined
in some circumstances and undefined in others.
Whether a value is given may be completely
optional or may depend on the value of the other
parameter.
"U" — User-defined parameter.
"-" — The parameter is not used.
"=" — (for Response only) Indicates that the value
of this parameter in the response must match that in
the primary (if defined).
1.6 Requirements — Requirements for recipe
management are varied. For example, there is a
fundamental need to retain information about each
recipe, to provide that information upon request, and to
transfer it with the recipe so that it remains available.
There is a need to classify recipes, to reuse them, and to
share them with multiple installations of equipment.
The need for sharing recipes introduces a new
requirement for safeguarding the relationship between a
recipe's identifier and its contents, to be able to protect
a recipe from unauthorized changes, and to ensure that
the identifier for a recipe that is used by multiple
equipment is in fact the same recipe.
The requirements for managing recipes in a factory are
given in tabular form in Table 1.1, which presents them
according to their functional areas and the specific
issues involved. Table R1-1, in Related Information,
shows the specific concepts defined in RMS to address
each of these requirements.