semi合集-English.pdf - 第1693页
SEMI E40-0705 © SEMI 1995, 2005 5 5.3.3 Service Message Definition — A service message definition table de fines the parameters used in a service, as shown in the following tab le: Parameter Req/Ind Rsp/Cnf Description P…
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
SEMI E40-0705 © SEMI 1995, 2005 6
widely applicable supervisory control capability for automated processing of material in equipment, irrespective of
the particular process being used.
7.1.1 This standard assumes that, given the material and the recipe specification, the processing resource is capable
of independently achieving the required processing objectives.
7.1.2 Processing management does not provide services for material movement, but the service-provider does need
to coordinate its activities with regard to the receiving and sending of material, thereby maintaining system integrity.
7.2 Process Job — The process job is a dynamic ob-ject specified by the process supervisor (service-user) to effect
material processing by the processing resource. The high-level job contains all the information required by the
processing resource to achieve processing of the material, once it arrives, without further intervention by the
supervisor.
7.2.1 The process job encompasses up to four sequential phases:
processing resource pre-conditioning before material arrival,
material and processing resource preparation for processing,
material processing, and
processing resource post-conditioning after material departure.
7.2.2 The material processing phase is the only phase in which the material is altered and is the only required phase.
7.2.3 This standard specifies services for the creation, control (pausing, aborting, etc.) and tracking of the process
job. It does not define the low-level control of processing since this is application-dependent. The processing
resource performing a process job is responsible for doing whatever is appropriate to achieve its processing
objectives, as specified by the recipe and tuning parameters.
7.2.4 The material specified in a process job may be the actual single material elements to be processed or a
container, such as in the case of a cassette of wafers.
7.2.5 The process job lifecycle may extend beyond the active processing of the material. It may exist from before
material arrival, through setup and processing, and until after material departure. This allows for material
processing-related pre-conditioning of the processing resource before the material is received and for processing
resource post-conditioning (e.g., cleanup) after material is sent. Pre-conditioning and post-conditioning support is
not a fundamental requirement.
7.2.6 The processing resource may provide process job queuing in order to offer flexibility in systems where work
is pre-scheduled or the order of material arrival is unknown. Queuing is the acceptance of multiple process jobs in
advance of performing the processing activities. Queuing is generally needed to support more complex systems
requiring concurrent and consecutive jobs (see below). The jobs are listed in the queue in the order created.
Execution order may be significant, such as consecutive jobs on the same material. Queuing is not a fundamental
requirement.
7.3 Relation to Material Movement — Processing Management does not provide services for receiving material into
the processing agent domain for processing or sending the material away after processing is complete.
7.3.1 Processing depends on the presence of the material, and material departure depends on process completion.
There is also an interdependency requiring synchronization with material movement if processing resource pre-
conditioning and post-conditioning are applied. The equipment is responsible for maintaining integrity between
material transfer and processing.
7.3.2 Material movement management is outside the scope of this standard but may be achieved using applicable
SEMI standards.
7.4 Processing Description — The description of the processing to be applied by the Process Job is crucial. The
description may be supplied in the form of a Process Recipe (see SEMI E42) or a Process Program (see SEMI E30).
This specification will define mes-sages referencing only Process Recipes. Where there are special considerations
for using Process Programs instead of a Process Recipe, they will be noted.