semi合集-English.pdf - 第1694页

SEMI E40-0705 © SEMI 1995, 2005 6 widely applicable supervisory co ntrol capability for automated pro cessing of material in equipment, irrespective of the particular process being used. 7.1.1 This standard assumes that,…

100%1 / 7923
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.
SEMI E40-0705 © SEMI 1995, 2005 7
7.4.1 The process job includes a processing descrip-tion (a recipe or process program) identifier that shall be unique
within the domain of the processing agent. The type and content of the processing description must be appropriate
for the processing resource and the type of material.
7.4.2 Creation and management of recipes and process programs is outside the scope of this standard.
7.5 Process Tuning — Feedforward and feedback control between process steps is becoming increasingly important
for process tuning in stabilizing processes, such as those which lack in-situ metrology, and demand increasing yields
(or performance). The process tuning requirements differ considerably with application, and there is little consensus
on any particular method. It is not the intention of this standard to provide compre-hensive support for process
tuning, but rather to provide a simple mechanism which may be extended. Support for recipe tuning is not a
fundamental requirement.
7.5.1 Processing management provides a mechanism for specification of the type of recipe method to be applied.
Two methods are defined in the standard: RecipeID only, and RecipeID and Variables. User-defined methods may
also be used, requiring all com-municating entities to have a common understanding of the particular definition and
application requirements.
7.5.2 The RecipeID only method accepts the identifier of the recipe to be applied but no additional tuning
parameters. The application recipe body is not precluded from defining any application tuning, but there is no
standardized support.
7.5.3 The RecipeID and Variables method provides a simple process tuning mechanism at process job creation to
support limited run to run feedforward and feedback control. It defines the VariableTuning method, which supplies a
list of variable names and values in the process job create. This sets variables defined in the recipe. Each variable
name shall be one of the exposed variable definitions supported in recipe management, and its value shall fall within
the range specified in the variable definition.
7.5.4 Recipe parameter names (RecipeVarName) shall be specified using the nomenclature defined for ‘Object
Specification’ (ObjSpec) in SEMI E39 (Object Services Standard) within the scope of SEMI E40 (Note: see
OBJSPEC in SEMI E5). This use of the ObjSpec nomenclature is required to unambiguously identify parameters
within some complex recipes (e.g., cluster tool process recipes). If the specification of a recipe parameter is
unambiguous, then the form of the ObjSpec may be simplified to just the parameter name. Using the ObjSpec
nomenclature for SEMI E40 recipe parameter names requires an object model to describe equipment recipe
structure.
7.5.5 Figure 1 shows an example of a typical set of cluster tool hierarchical recipe relationships. A processing
parameter might be specified through Sequence Step AB, Process Recipe BB, Process Step CB, to Process
Parameter DB. In this example, the object specifier for Process Parameter DB would be:
“Sequence:Erma>SequenceStep:AB>ProcessRecipe:
BB>ProcessStep:CB>ProcessParameter:DB>”
or
“Erma>AB>BB>CB>DB>”