semi合集-English.pdf - 第1654页

SEMI E38.1-95 © SEMI 1995 1 SEMI E38.1-95 COMM UNICATIONS ENVIRONMENT HSMS/SECS-I I FOR CLUSTER TOOL MODULE COMMUNI CATIONS 1 Purpose The purpos e of th is st andard is to speci fy th e communication environment for comm…

100%1 / 7923
SEMI E38-1296 © SEMI 1995, 1996 42
At this point, it is assumed that the cassette module
performs actions such as loadlock venting, door
opening, and initiating communication with the user
(human or host) to perform the handoff to the factory.
The cluster controller is informed of progress. When
the transfer to the factory is complete, the cluster
controller is informed.
CC CM
<<-------------------------------------<<
TRJobComplete.Req(JobID=IOJob8,
TimeStamp,Status=OK)
NOTICE: These standards do not purport to address
safety issues, if any, associated with their use. It is the
responsibility of the user of these standards to establish
appropriate safety and health practices and determine
the applicability of regulatory limitations prior to use.
SEMI makes no warranties or representations as to the
suitability of the standards set forth herein for any
particular application. The determination of the
suitability of the standard is solely the responsibility of
the user. Users are cautioned to refer to manufacturer’s
instructions, product labels, product data sheets, and
other relevant literature respecting any materials
mentioned herein. These standards are subject to
change without notice.
The user’s attention is called to the possibility that
compliance with this standard may require use of
copyrighted material or of an invention covered by
patent rights. By publication of this standard, SEMI
takes no position respecting the validity of any patent
rights or copyrights asserted in connection with any
item mentioned in this standard. Users of this standard
are expressly advised that determination of any such
patent rights or copyrights, and the risk of infringement
of such rights, are entirely their own responsibility.
Copyright by SEMI® (Semiconductor Equipment and Materials
International), 3081 Zanker Road, San Jose, CA 95134. Reproduction o
f
the contents in whole or in part is forbidden without express written
consent of SEMI.
SEMI E38.1-95 © SEMI 19951
SEMI E38.1-95
COMMUNICATIONS ENVIRONMENT HSMS/SECS-II FOR CLUSTER
TOOL MODULE COMMUNICATIONS
1 Purpose
The purpose of this standard is to specify the
communication environment for communication with
and among modules in a cluster tool.
2 Scope
The scope of this standard is communication within a
cluster tool as defined in the standard Cluster Tool
Module Communication Standard (CTMC, SEMI E38).
This standard specifies the transmission of SECS-II
messages by HSMS (SEMI E37), HSMS-GS (SEMI
E37.2), and Ethernet. Other methods of message
communication are possible but beyond the scope of
this standard.
This standard is intended to be one of possibly several
supplements to the CTMC SEMI E38.
3 Referenced Documents
3.1 SEMI Standards
1
The following SEMI standards are related to the
Communications Environment standard:
SEMI E5 — SEMI Equipment Communication
Standard 2 - Message Content (SECS -II).
SEMI E37 — High-Speed SECS Message Services
(HSMS) Generic Services
SEMI E37.2 — High-Speed SECS Message Services
General Session (HSMS-GS)
3.2 IEEE Standards
2
The following IEEE standard is related to the
Communications Environment standard:
IEEE 802.3 — Carrier Sense Multiple Access with
Collision Detection
4 Definitions
The following definitions are arranged in alphabetical
order. Some are defined using terms defined elsewhere
within this section. No definitions beyond this section
and the referenced standards should be necessary for a
basic understanding of these terms.
1
Semiconductor Equipment & Materials International, 805 East
Middlefield Road, Mountain View, CA 94043
2
Institute of Electrical and Electronics Engineers, 345 East 47th
Street, New York, NY 10017
10 BASE 2 — a common physical medium for the
transmission of Ethernet signals.
AUI (Attachment Unit Interface) — a specification of
the connector, pins, and signals used to interface a
computer to a MAU. Defined formally in IEEE 802.3.
Cluster Tool Environment — a collection of
interconnected modules forming a cluster tool.
Communications Stack — a specification of successive
layers of interfaces through which communication
services are provided.
Ethernet — a method of transmitting signals. Ethernet
is defined formally by IEEE 802.3
MAU (Medium Attachment Unit) — an adaptor from
the AUI interface to a physical wire or medium such as
10 BASE 2. Defined formally in IEEE 802.3
Platform — a physical computer in a cluster tool that
contains the Ethernet Interface or station as defined in
IEEE 802.3. In a cluster tool, a platform may have one
or more logical modules residing on it.
5 Required Sessions
In order to support the Services specified in the CTMC
standard, there is an associated set of Protocol standards
that specify a set of SECS-II messages to support these
Services. This standard specifies the transmission of
these SECS-II messages using HSMS sessions.
In order to communicate with a given logical module, a
separate HSMS connection (TCP/IP connection) is
required per logical module.
For correct operation of a cluster tool using these
facilities, a set of standard sessions, given in Table 1, is
required. Other sessions are possible, but are not
required. In order to be compliant a module must not
require further sessions in order to operate.
Table 1 Required Sessions
Client Server Services
Cluster Controller Transport
Module
Object Services,
Material Movement,
Exception Management,
Event Reporting
Cluster Controller Cassette
Module
Object Services,
Material Movement,
Exception Management,
Event Reporting
SEMI E38.1-95 © SEMI 1995 2
Client Server Services
Cluster Controller Process
Module
Object Services,
Processing Management,
Recipe Management,
Material Movement,
Exception Management,
Event Reporting
Cassette Module Transport
Module
Object Services,
Material Movement
Process Module Transport
Module
Object Services,
Material Movement
6 Communication Stack Sp ecification
There are many layers of software required in order to
communicate using a facility such as HSMS. In order to
interoperate, modules shall have identical or equivalent
protocols at each layer on both sides of a physical
connection.
HSMS does not specify a particular physical layer. In
order to ensure interoperability between modules, of
possibly different origin, a complete interoperable
communication stack is required.
6.1 SECS-II Messages — The Cluster Tool Module
Communications (CTMC) standard specifies a set of
messaging services from applicable standards for use
by a cluster tool module. Each service standard has a
supplemental protocol standard which defines the
SECS-II message support. This standard specifies a
method for transporting these SECS-II messages. In
order to be compliant with this standard, these SECS-II
messages must be used. The detail of the SECS-II
messages is found in SEMI E5. SECS-II message
definitions refer to messages communicating between a
host and equipment. With reference to implementing
CTMC, the host is the service-user or cluster-
controlling entity, and the equipment is the service-
provider or cluster module entity.
6.2 HSMS Messaging — For the purposes of
communication of SECS-II messages within the cluster
tool communication environment, SEMI High-Speed
SECS Message Service (HSMS) shall be used (SEMI
E37).
CTMC defines a number of services. For inter-module,
and service user-to-module communication, many
services will be required simultaneously. As a result,
the capabilities of the HSMS General Session (SEMI
E37.2) are required and shall be used for
communication of all services specified by the CTMC.
6.2.1 IP Addresses, Port Numbers, and Session IDs —
HSMS defines the setting of IP Addresses, Port
Numbers, and Session IDs. In order to uniquely specify
a service, all three are required as configuration
parameters. The actual numbers shall be within the
allowed range and unique within their respective
domains. Table 2 shows these parameters, what they
define, and their respective domains.
Table 2 Configuration Parameters
Parameter Defines Domain of Uniqueness
IP Address Platform Network
Port Number TCP/IP Connection Platform
Session ID CTMC Service TCP/IP Connection
6.2.2 Session ID’s — Each association required by
CTMC (such as Processing, Material Movement,
Exception, etc.) shall have a session within a
connection. These Session ID’s shall be documented by
the service provider, and, if configurable, the method of
configuration shall be documented.
The Session ID for a given service shall be defined and
may be dictated by the service provider (at the server
end of a connection).
In order to use a service, the service user (which is the
client end of the connection) shall select the service by
Session ID. Thus, the Session ID shall be configurable
for the service user and the method of configuring shall
be documented for each service user. Session IDs shall
be as shown in Table 3.
Object services shall use Session ID 1; all other
services shall use Session ID’s from the range labeled
“Available” in Table 3.
Table 3 Allowed Session ID’s
Session ID Service
0 Reserved
1 Object Services
2-63 Reserved (future)
64-65534 Available
65535 (OxFFFF) Reserved (HSMS)
6.2.3 Linktest — The linktest procedure is an optional
facility of HSMS. For the purposes of cluster tool
communications, the linktest procedure as described in
the HSMS standard shall be supported. On detection of
a linktest timeout, a communication failure will be
considered to have occurred, and higher communication
layers shall be notified of this failure.
6.2.4 Connection Mode — HSMS provides for Active,
Passive, and Alternating Connection Modes. For the
purposes of establishing connections in a cluster tool,
either Active or Passive shall be used. For each service
provided, there is a service provider (server) and a
service user (client). With respect to each service, the