semi合集-English.pdf - 第1692页
SEMI E40-0705 © SEMI 1995, 2005 4 transitions. In certain implementations, the equipment may enter a state and h ave already satisfied all of the conditions required by the Processing Management state m odels fo r transi…
SEMI E40-0705 © SEMI 1995, 2005 3
4.2.14 service-user — the software control entity that is the user of any of the related services.
4.2.15 supervisor — an entity or entities having supervisory control responsibilities for one or more processing
resource. It is the service-user of the processing management services.
4.2.16 tuning — specification of information which supplements the pre-defined recipe used to achieve the
particular process goals.
4.3 Data Type
4.3.1 boolean — may take on one of two possible values, equating to TRUE or FALSE.
4.3.2 enumerated — may take on one of a limited set of possible values. These values may be given logical names,
but they may be represented by any single-item data type.
4.3.3 form — type of data: positive integer, unsigned integer, integer, enumerated, boolean, text, formatted text,
structure, list, ordered list.
4.3.4 formatted text — a text string with an imposed format. This could be by position, by use of special characters,
or both.
4.3.5 integer — may take on the value of any negative or unsigned integer. Messaging protocol may impose a limit
on the range of possible values.
4.3.6 list — a set of one or more items that are all of the same form (one of the above forms).
4.3.7 ordered list — a list for which the order in which items appear is significant.
4.3.8 positive integer — may take the value of any positive whole number. Messaging protocol may impose a limit
on the range of possible values.
4.3.9 structure — a complex structure consisting of a specific set of items, of possibly mixed data types, in a
specified arrangement.
4.3.10 text — a text string. Messaging protocol may impose restrictions, such as length or ASCII representation.
4.3.11 unsigned integer — may take the value of any positive integer or zero. Messaging protocol may impose a
limit on the range of possible values.
5 Conventions
5.1 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.
5.1.1 The Harel notation does not include the concept of “creation” and “deletion” of state models to represent
transient entities. The “job” described in this document is such an entity, where each new job created uses a copy of
the same state model. In this document, an oval is used to denote the creation of an entity and also the deletion of
that entity.
5.1.2 Transition tables are provided in conjunction with the state diagrams to describe explicitly the nature of each
state transition. A transition contains columns for Transition #, Current State, Trigger, New State, Action(s). The
“trigger” (column 3) for the transition occurs while in the “current” state. The “actions” (column 5) include a
combination of (1) actions taken upon exit of the current state, (2) actions taken upon entry of the new state, and (3)
actions taken which are most closely associated with the transition. No differentiation is made.
5.1.3 The state models included in this standard are a requirement for Processing Management compliance. A state
model consists of a state model diagram, state definitions, and a state transition table. When using SEMI E30, E53
or similar style collection events, all state transitions in this standard, unless otherwise specified, shall correspond to
collection events.
5.1.4 A state model represents the host’s view of the equipment, and does not necessarily describe the internal
equipment operation. When using collection events, all Processing Management state model transitions shall be
mapped sequentially into the appropriate internal equipment collection events that satisfy the requirements of those
SEMI E40-0705 © SEMI 1995, 2005 4
transitions. In certain implementations, the equipment may enter a state and have already satisfied all of the
conditions required by the Processing Management state models for transition to another state. In the case, the
equipment makes the required transition without any additional actions in this situation.
5.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 Requirement Form
The formal text name of the attribute. Description of the information contained. RO or RW Y or N (see below)
5.2.1 The Access column uses RO (Read Only) or RW (Read and Write) to indicate the access that service-users
have to the attribute.
5.2.2 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.
5.2.3 The Form column is used to indicate the format of the attribute. (See ¶4.1 for definitions.)
5.3 Service Message Representation
5.3.1 Service Resource Definition — A service resource definition table defines the specific set of messages for a
given service group, as shown in the following table:
Message Service Name Type Description
Message Name N or R The intent of the service.
5.3.1.1 Type can be either N = Notification or R = Request.
5.3.1.2 Notification type messages are initiated by the service provider, and the provider does not expect to get a
response from the consumer/subscriber.
5.3.1.3 Request messages are initiated by a service consumer or subscriber. Request messages ask for data or an
activity from the provider. Request messages expect a specific response message (no presumption on the message
content).
5.3.2 Service Parameter Dictionary — A service parameter dictionary table defines the parameters used in a
service, as shown in the following table:
Parameter Form Description
Parameter X Data Type A parameter called X is B in A.
5.3.2.1 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.
5.3.2.2 The Form column is used to indicate the type of data contained in a parameter. (See ¶4.2 for definitions.)
5.3.2.3 The Description column in the Service Parameter Dictionary table describes the meaning of the parameter,
the values it can take on, and any inter-relationships with other parameters.
5.3.2.4 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.
SEMI E40-0705 © SEMI 1995, 2005 5
5.3.3 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/Cnf Description
Parameter X (see below) (see below) A description of the service.
5.3.3.1 The columns labeled Req/Ind and Rsp/Cnf link the parameters to the direction of the message. The message
sent by the initiator is called the “Request.” The receiver terms this message the “Indication” or the request. The
receiver may then send a “Response,” which the original sender terms the “Confirmation.”
5.3.3.2 The following codes appear in the Req/Ind and Rsp/Cnf 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).
6 Overview
6.1 Processing management is concerned with the processing of material by a processing resource. Its principle
function is to ensure that material delivered to the processing resource is processed with the correct recipe. It defines
the services needed by a supervisor (service-user) to initiate and track processing of a particular material. It also
defines commands which affect the processing operation.
6.1.1 The processing resource is the entity which adds manufacturing value to the material. It may take several
forms, including the processing element of a cluster tool process module or the entity managing processing for a
complete stand-alone equipment. The processing agent is considered to be the provider of the processing services.
6.1.2 Process management allows for pre-conditioning before material arrival and post-conditioning after material
departure. A simple tuning mechanism provides support for limited feedforward and feedback control. The tuning,
applied at process initiation, sets recipe variable parameters.
6.1.3 The services are fully defined in terms of the functionality provided by the processing agent (service-provider)
and, as such, do not dictate the architecture of the supervisor (service-user).
6.1.4 This standard describes the concepts and processing model on which the communications are based, followed
by the detailed behavioral model used. It then describes the standard object attributes and message services in detail.
6.2 Compliance — Compliance to this standard includes adherence to all stated requirements in this document
where implemented. Standard services are to be used where related functionality is required. This includes defined
message services and state models.
6.2.1 Some capabilities are not required to be supported for compliance, such as queuing, multiple concurrent jobs,
material groups, manual start, pause/resume, and tuning. Required capabilities are indicated throughout the
document and are also listed in the Fundamental Requirements section.
6.2.2 A processing agent shall provide the funda-mental requirements, plus the set of optional services, appropriate
to achieve effective processing management for the particular hardware architecture and automated processing
requirements.
7 Concepts
7.1 Material Processing Model — Processing management ensures that the appropriate processing is applied to a
particular material by a processing resource through the definition of a process job. The process job provides a