semi合集-English.pdf - 第1616页
SEMI E38-1296 © SEMI 1995 , 1996 5 From a mechanical vi ewpoint, Cluster Tool Module In terface standards-com p liant equipm en t has a physical structure w here process m odules and cass ette modules are attached in a s…
SEMI E38-1296 © SEMI 1995, 1996 4
4.1.49 transfer resource — a module resource within a
transport module independently capable of transferring
material from one attached module to another.
4.2 Data Type
4.2.1 form — type of data: positive integer, unsigned
integer, integer, enumerated, boolean, text, formatted
text, structure, list, ordered list.
4.2.2 positive integer — may take the value of any
positive whole number. Messaging protocol may
impose a limit on the range of possible values.
4.2.3 unsigned integer — may take the value of any
positive integer or zero. Messaging protocol may
impose a limit on the range of possible values.
4.2.4 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.2.5 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.2.6 boolean — may assume one of two possible
values, equating to TRUE or FALSE.
4.2.7 text — a text string. Messaging protocol may
impose restrictions, such as length or ASCII
representation.
4.2.8 formatted text — a text string with an imposed
format. This could be by position, by use of special
characters, or both.
4.2.9 structure — a complex structure consisting of a
specific set of items, of possibly mixed data types, in a
specified arrangement.
4.2.10 list — a set of one or more items that are all of
the same form (one of the above forms).
4.2.11 ordered list — a list for which the order in
which items appear is significant.
5 Conventions
5.1 Harel State Model
5.1.1 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.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.2 OMT Object Information Model — The object
models are presented using the Object Modeling
Technique developed by Rumbaugh, James, et al., in
“Object-Oriented Modeling and Design,” Prentice Hall,
Englewood Cliffs, NJ, ©1991. Overviews of this
notation are provided in an appendix to SEMI E39.
5.3 Object Attribute Representation — The object
information models for standardized objects will be
supported by an attribute definition table with the
following column headings:
Attibute Name Definition Access Rqmt Form
The formal
text name of
the attribute.
Description of
the
information
contained.
RO or RW Y or N (see
below)
The Access column uses RO (Read Only) or RW (Read
and Write) to indicate the access that service-users have
to the attribute.
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.
The Form column is used to indicate the format of the
attribute. (See Section 4.1 for definitions.)
6 Overview
The Cluster Tool Module Communications standard
specifies the communications services necessary to
achieve automated control within a cluster tool. It
defines the essential cluster tool architecture and the
concepts and models on which the communications
services are based.
Cluster tools provide a means of grouping a number of
independent process steps into a single equipment. The
primary function of a cluster tool is material processing.
Material enters the cluster tool, undergoes a number of
sequential process steps which adds value to the
material, and then exits.
SEMI E38-1296 © SEMI 1995, 19965
From a mechanical viewpoint, Cluster Tool Module Interface standards-compliant equipment has a physical
structure where process modules and cassette modules are attached in a standardized way to some form of transport
module, a robotic material handler operating in an isolated environment. Cassette modules provide the input and
output of material for the cluster tool, usually in cassettes.
This communications standard enables the distributed control of these cluster tools, and of other cluster tools and
multi-resource equipment which can be decomposed into process, transport, and cassette modules, whether
environmentally isolated or not. A basic assumption is made that the primary human-machine interfaces are not
located at the individual modules.
Communication and control services are specified among service-users and service-providers within a cluster tool.
The service-providers are the controlled processing, transfer, intratool port, and intertool port resources in the
appropriate modules. The service-users are the application entities responsible for supervisory control and data
acquisition within the cluster tool.
The services are fully defined in terms of the service-providers, and as such, do not dictate the architecture of the
service-user(s). An example of cluster tool control architecture is shown in Figure 1, where the service-user is a
single cluster controller platform providing internal scheduling, human-machine interface, and standardized
communications interface to the factory.
Figure 1
Example Cluster Control Architecture
The communication services include primary control services for material processing in process modules
(processing management) and material movement within the cluster tool and material input/output with the factory
(material movement management). The cluster controller, which is responsible for supervisory control within the
cluster tool, is the service-user of these primary control services. The form of the cluster controller is not dictated. It
may be a single platform, distributed, or incorporated with one or more modules.
Support services are also specified to enable resolution of exception conditions, recipe handling, event reporting and
data access. The decision authority, which is responsible for making error recovery decisions, is the service-user for
exception management. Appropriate agents are the designated service-users for the recipe management and event
reporting support services. All service-users access data using the Object Services.
The communications services are defined independently of protocol in order to allow future standardization of
alternative protocols without invalidating the services. Figure 2 shows the full communications stack needed for
compliance, where the services are mapped to the communications environment, which is defined in supplementary
standards.
SEMI E38-1296 © SEMI 1995, 1996 6
Figure 2
Cluster Tool Module Communications Standards
This standard describes the cluster tool model on which
the communications are based. It then defines the
application of each of the services required within a
cluster tool. This includes limitations imposed by the
cluster architecture as well as clear a statement of the
fundamental requirements in order to minimize the
implementation effort. Connection establishment and
maintenance are defined together with the requirements
of the communications environment. Communications
environment is described in a subsection in order to
allow additional options to be standardized in the
future. The application notes include factory integration
issues and an example scenario of standard
communications for the lifecycle of a single material in
a cluster tool.
6.1 Compliance — Cluster tool module
communications compliance between entities in a
cluster tool requires that all applicable exposed
interfaces conform to the standards specified in this
document.
The standardized interfaces are:
• Process module to Service-user (cluster controller)
• Transport module to Service-user (cluster
controller)
• Cassette module to Service-user (cluster controller)
• Transport module to Cassette module
• Transport module to Process module
The exposed interfaces are those which result from a
particular partition of the control entities in a cluster
tool which are from independent suppliers. Three
examples follow:
1. All modules independent, single cluster controller
platform: Interfaces are required between the
cluster controller and each module, and between
the transport module and each process and each
cassette module.
2. Material handler, process modules independent,
single cluster controller platform: Interfaces are
required between the cluster controller and each
process module, between the cluster controller and
each logical module in the material handler
(transport and cassette modules), and between the
material handler and each process module.
3. One independent process module integrating to a
cluster tool control system: Interfaces are required
between the cluster tool control system and the
process module supporting the process module to
cluster controller communications, and the process
module to transport module communications.
For fundamental compliance, each exposed interface
shall support the fundamental requirements of each of
the service groups required by the entities
communicating. The required service groups for each
interface are detailed in Section 8.6, and the required
services for each service group are detailed in Sections
8.1 to 8.6.
7 Concepts
The Cluster Tool architecture and requirements are
modeled in order to extract only the entities necessary
for robust automated control and monitoring
communications within a cluster tool.
Figure 3 illustrates the major module domains and the
primary relationships between them. Module resources
and material domains are represented differently to
others because they embody the physical entities acting
and being acted upon respectively.