semi合集-English.pdf - 第1619页
SEMI E38-1296 © SEMI 1995 , 1996 8 Figure 4 Object Desi gnation In addition to OMT co nven tions (see Section 5.2), each object in th e information models ha s one of three designat ions: s ervice objects with standardi …
SEMI E38-1296 © SEMI 1995, 19967
Figure 3
Cluster Tool Module Illustration
The domains illustrated are as follows:
Material — The material, or carrier of material, which
is being received and processed in the cluster tool.
Material Processing — Specifies the required
application of processing to material as defined by the
assigned recipe, adding value to the material.
Material Movement — Includes exchange of material
with the factory and material movement within the
cluster, to get the material to the correct processing
resource at the right time.
Module Resources — Perform and coordinate the
processing and material movement activities.
Recipe Management — Provides the services to transfer
recipes to be loaded as required for material processing,
and manages recipe change control.
Exception Handling — Provides for interactive
handling of exception conditions, including reporting
and error recovery.
Event Reporting — Enables flexible event-based
reporting of variable data as required by service-users.
Object Services — Provide services to obtain and
modify standard object attribute data.
Each partition is presented in a subsection below with
detailed information models.
The concepts are presented in this section using two
types of formal models: OMT object information
models describing entities and relationships, and Harel
state models describing the behavioral characteristics of
the cluster tool. The graphical representations of these
models are described in Conventions, Section 5.
The events and actions which result from objects
dynamically interacting form the basis for the
communication requirements embodied in the
standards. It is this mapping that specifies the
communication services messages to be used.
The major requirement of the cluster tool control
system is that it provide robust supervisory control with
minimal overhead. Within a cluster tool there is a
significant amount of parallel processing. In addition to
concurrent processing in multiple independent process
modules, each material processing requires the use of
recipe management (to get the correct recipe with the
correct material) and the use of material movement (to
get the correct material to the correct processing
resource at the right time).
The cluster controller maintains the overall mission of
the system. Sub-missions are defined for, and
responsibility given to, particular available module
resources for execution. Once this responsibility is
given, that module resource is fully in control,
including direct communication with resources of other
modules as required to attain the objective.
7.1 Object Information Models — The cluster tool
objects relevant to distributed control in a number of
models, each emphasizing a particular aspect of the
system as partitioned (see Figure 4).
SEMI E38-1296 © SEMI 1995, 1996 8
Figure 4
Object Designation
In addition to OMT conventions (see Section 5.2), each
object in the information models has one of three
designations: service objects with standardized
attributes (thick border); other objects described in the
sub-section (medium border); and objects described in
other subsections but included to show significant
relationships (thin border).
The models are process- and configuration-independent
and do not dictate the internal architecture of the
controlled modules beyond the physical requirements of
cluster tools.
The first two models show major entities of the
processing equipment and material being processed.
Subsequent models are oriented towards one of the
major functional domains.
7.1.1 Cluster Tool Module Model — The fundamental
component of a cluster tool is the module. Figure 5
shows that there are three module types within a cluster
tool:
Figure 5
Cluster Tool Module Information Model
SEMI E38-1296 © SEMI 1995, 19969
• process module (PM)— provides manufacturing
value to material
• transport module (TM) — transfers material within
cluster
• cassette module (CM) — exchanges material with
factory
A cluster tool must contain one or more of each of these
module types, as each performs a critical function in the
cluster tool mission. Any module can contain
processing resources.
Supervisory control within the cluster tool is the
responsibility of the cluster controller. The cluster
controller achieves this by supervising the various
module resources using the standard communications
services. It is the primary service-user in the cluster
tool. The form of the cluster controller is not specified
in this standard. It may be a single platform, distributed,
or incorporated with one or more modules.
A module contains and coordinates a number of module
resources dedicated to fulfilling a particular control
function. Each module resource contains at least one
material location, which may or may not contain
material. Note that the location for material processing
is defined separately from the location where the
material is received or sent. This may be virtual if they
are physically the same position, but they cannot be
assumed to be so as this would exclude certain
architectures.
The purpose of each type of module is described in
detail below.
Cassette Module — The component of a cluster used to
interface the cluster to the rest of the factory. It
provides material input and output for the cluster. It
makes only one material at a time available to the
cluster transport (the intratool environment), regardless
of how the material enters the cassette module from
outside the cluster (the intertool environment). It is a
specialization of attached module (AM).
Process Module — A process module is any component
within a cluster which provides one or more steps of
material processing for the cluster system. Material
enters the process module through an interface flange,
undergoes some transformation, and exits through the
same or another interface flange. It is also a
specialization of attached module (AM).
Transport Module — The transport module is
responsible for transfer of material from one cluster-
attached module to another. It consists of a robotic
handler capable of exchanging material with each of the
attached modules at the interface flanges. It can be a
variety of physical topologies (radial or linear, for
example). In SEMI standard cluster tools, the transport
module has an interface isolation valve at each point of
attachment to the attached modules. The transport
module is responsible for managing constraints on the
simultaneous opening of isolation valves as it relates to
contamination of the transport module's environment by
that of an attached module, as well as cross
contamination between attached modules.
The attributes of modules and related objects in Figure
5 are not standardized as these objects are equipment
and process-dependent.
7.1.2 Material Model — Material is received from the
factory, in a carrier or singly, at an intertool port
resource. They are transported within the cluster and
processed by processing resources. Once processed,
they are returned to the factory at the same, or another,
intertool port resource.
The processing which is to be performed on material is
determined from the process specification for that
material.
The material model in Figure 6 establishes the
relationships between the material and material
locations. Two material types are of interest in cluster
tool module communications, single material and
carriers. Single material may be grouped in carriers.
This is modeled by defining the material slot object,
which is a type of material location. A carrier is made
up of an ordered set of material slots. A single material
occupies a material slot when in the carrier. In addition,
a single material may be assigned a particular material
slot which it does not yet occupy, indicating that it is to
be received into that material slot when it arrives.
Figure 6
Material Information Model