semi合集-English.pdf - 第1656页

SEMI E38.1-95 © SEMI 1995 3 client shall connect in the Active mode an d the server in the Passive m ode. Table 1 specifies the client and server (an d hence conn ection mode) of the required sessio ns. In addition to es…

100%1 / 7923
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.
SEMI E38.1-95 © SEMI 1995 4
APPENDIX 1
APPLICATION NOTES
NOTE: This appendix was approved as a part of SEMI E38.1 by full letter ballot procedure.
A1-1 Example Configuration
The following example shows configuration of a cluster
tool consisting of an existing process module with a
new cluster controller and other modules.
The cluster consists of a Cluster Controller, two Process
Modules (PM1, PM2), and a combined
Transport/Cassette Module (TM/CM).
A1-1.1 IP Addresses — IP addresses are chosen so that
they are unique to each platform on the network and
consistent with the conventions used at the facility. For
this example, the convention is to use 192.25.63.X for
IP Addresses, where X is between 0 and 255. PM1 had
an existing IP address of 192.25.63.122, which will not
be changed. IP addresses starting at 205 are unused and
thus available. Thus, the following IP addresses are
chosen:
Cluster Controller 192.25.63.205
TM and CM 192.25.63.206
PM1 192.25.63.122
PM2 192.25.63.207
As part of the configuration, the IP Address of each
module is identified as shown above, on all of the
platforms. This configuration depends on the TCP/IP
software used on the respective platforms.
A1-1.2 Port Numbers — TCP reserves port numbers
below 1024 in RFC1340. There are no other TCP/IP
programs on any of the platforms in the cluster using
port number in the range 2000-10000, so the following
port numbers are chosen:
2000 first TM
5000 first CM
8000 first PM
8001 second PM
The cluster controller is always a client and initiates the
connections, so no port number assignment is required.
A1-1.3 Session ID Assignment — Before defining the
Session ID’s, recall that the following connections are
required:
Client Server
CC TM
CC CM
CC PM1
CC PM2
CM TM
PM1 TM
PM2 TM
The Session ID’s are arbitrary. PM1 already has ID’s
which are as follows:
PM1 IDs
Clients
Object Services 1 CC, TM
Processing Management 100 CC
Recipe Management 101 CC
Material Movement 102 CC, TM
Exception Management 103 CC
Event Reporting 104 CC
The other modules have not yet been set, so we choose
to begin with ID 64.
The session IDs are established as follows:
PM2 Ids
Clients
Object Services 1 CC, TM
Processing Management 64 CC
Recipe Management 65 CC
Material Movement 66 CC, TM
Exception Management 67 CC
Event Reporting 68 CC
TM IDs
Clients
Object Services 1 CC
Material Movement 64 CC
Exception Management 65 CC
Event Reporting 66 CC
CM IDs
Clients
Object Services 1 CC, TM
Material Movement 64 CC, TM
Exception Management 65 CC
Event Reporting 66 CC