semi合集-English.pdf - 第1742页

SEMI E42-0704 © SEMI 1995, 2004 11 Table 1.1 Requirements Functional Areas Issue Requirements Management of Recipes Identifica tion Uniquely store, identif y, and select recipes in a system. Easy and clear i dentificatio…

100%1 / 7923
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.
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.