semi合集-English.pdf - 第1628页
SEMI E38-1296 © SEMI 1995 , 1996 17 Figure 19 Cluster Tool Material State Model When ready to be process ed in the cluster tool, th e material is presented an d loaded at the input cassette m odule (intertool material tr…

SEMI E38-1296 © SEMI 1995, 1996 16
Figure 15
Transport Module Primary Control Message Flow
Figure 16
Module Exception Message Flow
Figure 17
Module Recipe Message Flow
Figure 18
Module Event Reporting Message Flow
The communications for support functionality are
shown for any module, as the services are common to
all module types. The support functionality modeled
includes exception handling (Figure 16), recipe
management (Figure 17), and event reporting (Figure
18). A typical decision authority or service-user is the
cluster controller.
7.3 Cluster Tool Behavioral Model — The process
material is the fundamentally important object in a
cluster tool and its lifecycle is the key component to
establishing cohesiveness in the communication and
controls standards.
The finite state model in Figure 19 presents the high-
level behavior of a single material within the domain of
the cluster tool. Bold transitions trace the normal
lifecycle of the material and are described in the
transition table, Table 1. Other transitions occur in
exception situations and are not detailed here. The
transition table actions indicate the primary control
operations which are requested of the modules by the
cluster controller.

SEMI E38-1296 © SEMI 1995, 199617
Figure 19
Cluster Tool Material State Model
When ready to be processed in the cluster tool, the material is presented and loaded at the input cassette module
(intertool material transfer). It is usually contained with other single material in a cassette. The material process sub-
state in the scope of this visit to the cluster tool is initially unprocessed. The material is then transferred to the first
process module (intratool material transfer), ready for process. At this point, the material may be returned to the
input cassette module and back to the factory, as the material has not been physically altered.
The material then begins processing in the process module according to the recipe for that process step (process job),
and the process sub-state changes to in-process.
On successful completion of the process step, the material is then ready to be transferred to the next module
(intratool material transfer). This may be another process module for the next process step or to the output cassette
module if processing in the cluster tool is complete, in which case the process sub-state changes to processed. It is
also possible that the next process step be performed in the same process module.
Table 1 Cluster Material State Transition Table
# Current State Trigger New State Action(s)
1 Ready for
Processing in cluster
Material being received at cluster CM. In cluster tool CM Input/Output Transfer Job. CM
Carrier mapping.
2 Not in Cluster tool Material being received at cluster CM. Arrived input CM
3 Not in Cluster tool Material being received at cluster CM. Unprocessed
4 Arrived input CM Initiate material transfer to PM. Transferring
between modules
Initiate PM Process Job. TM Transfer
Job. Source AM Transfer Job (CM send).
Dest. AM Transfer Job (PM receive).
5 Transferring
between Modules
Material arrived in PM. In PM/Arrived input
port
6 In PM/Arrived input
port
Processing initiated on material. In PM/Processing PM Process the material.
7 Unprocessed Processing initiated on material. In Process
8 In PM/Processing PM processing complete. In PM/Ready output
port
9 In Process All required process steps in cluster
completed.
Processed
10 In PM/Ready output
port
Initiate intratool material transfer. Transferring
between modules
Initiate next PM Process Job if material
processing still required. TM Transfer
Job. Source AM Transfer Job (send).
Dest. AM Transfer Job (receive).

SEMI E38-1296 © SEMI 1995, 1996 18
# Current State Trigger New State Action(s)
11 Transferring
Between Modules
Arrived output CM. Arrived output CM CM Input/Output Transfer Job.
12 Arrived output CM Transfer back to factory complete. Processing in cluster
complete
The material is finally unloaded from the output
cassette module to the factory (intertool material
transfer). If all process steps in the cluster tool were
completed and were successful, the processing in the
cluster tool is complete; otherwise, processing in the
cluster tool was only partially accomplished.
Detailed behavioral models are documented in the
individual Cluster-Specific Services and in the
standards which they reference. The Typical Operating
Scenario in the application notes illustrates the
behavioral characteristics of cluster tool control by
showing the detailed messaging among modules and
supervisory controller through the lifecycle of material
as it enters the cluster, is processed, and then leaves the
cluster.
7.4 Cluster Tool Control Topology — The natural
decomposition of a cluster tool is into its modules. The
module controller is the entity which performs internal
control of a module and provides standard services.
Module controllers provide certain application-specific
functions (providers of services and user of services)
and consist of hardware and software components that
interact with the communications and control
environment of the cluster tool.
Traditional definitions of controllers have implied
certain PHYSICAL, hardware control topologies (such
as distributed or centralized processors). These cluster
tool standards specify the communications in terms of
services-providers, enabling the module controllers to
be based on LOGICAL control topologies.
The list of possible physical controllers which could be
used to implement the logical services of the standards
are listed below. It is emphasized, however, that the
standard is not based on any constraint that each of
these physical controllers be present in a cluster control
system, but instead requires that the logical services
(i.e., software functional components) be present
somewhere in the cluster control system.
Possible Controllers:
• Cassette Module Controller
• Process Module Controller
• Transport Module Controller
• Cluster Controller
The logical control topology allows any combination of
module controllers on a single control unit. Standard
communication is not required among them. A common
example is the grouping of transport module and
cassette module control into a single material handler
control unit as shown in Figure 1. For interface
compliance, all communication between a logical
module controller and remote controller or service-user
must be compliant with the standard services.
8 Cluster Tool Module Serv ices
The Cluster Tool control system elements, as
represented in the object information, object
communications, and behavioral models, require
standard services in order to interface with one another.
The objects which are fully standardized (attributes,
behavior, and operations) are only those essential to this
communication, and the services are the interactions
with these standard objects.
The services are grouped into the following functional
areas:
• Object Services
• Processing Management
• Material Movement Management
• Exception Management
• Recipe Management
• Event Reporting
• Clock
The services of each of these groups are described in
detail in this section. The services are defined in terms
of services provided by independent SEMI standards,
specifying their application and limitations with respect
to the fundamental requirements of cluster tool module
communications.
8.1 Object Services — All standardized service object
attribute access across a cluster tool module
communications interface is achieved using object
services. Access may be to read attribute values of
objects, to get a list of objects corresponding to certain
criteria, and to set the values of writable attributes of
objects. The message services provided to accomplish
this are Get and Set.