semi合集-English.pdf - 第1655页
SEMI E38.1-95 © SEMI 1995 2 Client Server Serv ices Cluster Control ler Proces s Module Object Servi ces, Proces sing Manag eme nt, Recipe Manageme nt, Material Mov ement, Exce ption Mana gem ent, Event Re porting Cass e…

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

SEMI E38.1-95 © SEMI 19953
client shall connect in the Active mode and the server in
the Passive mode. Table 1 specifies the client and
server (and hence connection mode) of the required
sessions.
In addition to establishing the connection, the client
shall initiate the sessions with the Select message, as
defined in HSMS. As a result, all sessions at the client
end of a connection shall be service users and all
sessions at the server end of the connection shall be
service providers.
6.3 Use of TCP/IP — HSMS defines the use of
TCP/IP for communication of messages. Other
simultaneous uses of TCP/IP are possible but beyond
the scope of this standard.
Within TCP, Port Numbers are used to uniquely
identify the connection on a given platform. A port
number may be any value between 0 and 65535, but
TCP reserves port numbers starting at 0. Refer to
HSMS and the references given in HSMS for the
definition of the reserved port numbers.
Multiple logical modules may exist on a given
platform. Each service for a logical module on a given
platform must use a unique session within a connection.
It is possible to configure a module so that each logical
module uses a separate connection, but it is also
possible for several logical modules to share a
connection. Each service requires a unique connection
for each external entity, but an external entity may,
depending on the configuration, access the services of
several logical modules on a platform, identifying them
by unique session, except for Object Services. Object
Services is always identified by Session ID 1.
Connection to a specific module shall be established
using a non-reserved port number which is unique
among modules on that platform. A given service may
have several simultaneous connections.
6.3.1 Setting Port Number — The port numbers used
for establishing HSMS connections shall be
configurable for both the service user and service
provider. This is because the port numbers may be used
by some other software entity on the same platform.
Port numbers shall be chosen that are not in the
reserved range and do not conflict with any other
software entity on the platform. The method of
configuration of the port numbers shall be documented.
6.4 Physical Layer — HSMS allows for many
different physical layers. In order for modules to
interoperate, a single physical layer is required. This
standard specifies Ethernet — as defined in the standard
IEEE 802.3 — to be used for physical layer
transmission of HSMS messages.
Other physical layers could be used, but the use of other
such physical layers is not supported by this standard. It
is anticipated that other related standards will be
developed to support other physical layers. In such a
case, only those modules compliant with the same
standard would be interoperable.
6.5 Media and Connectors — With Ethernet, there is a
choice of media used (twisted pair, coax, etc.). It is
beyond the scope of this standard to specify the media
used. The media is thus left to the configuration of a
specific cluster tool and may depend on the available
media used in the factory.
Most Ethernet interfaces provide a media-independent
AUI interface. A transceiver is then used to access the
physical media. In order to be compliant with this
standard, a module shall provide an AUI interface.
Many interfaces also provide a media-specific interface.
This media specific interface may be used in the event
that the cluster tool media is the same as the media
specific interface.
7 Compliance
Compliance with this standard includes adherence to all
stated requirements where implemented. In order to be
compliant to this standard, an implementation shall:
1. use SECS-II messages as specified by CTMC
document,
2. use SEMI E37 (HSMS) and SEMI E37.2 (HSMS-
GS),
3. allow and document IP Address configuration,
4. allow and document Session ID configuration,
5. allow and document Port ID configuration,
6. use Ethernet as defined in IEEE 802.3,
7. provide an AUI connector.
Some Ethernet interfaces provide additional connectors
(such as 10 BASE 2 or thinnet). These may be used in
cases where this is the medium chosen, but for
compliance, an AUI connector shall be provided.