semi合集-English.pdf - 第1580页

SEMI E37-0303 © SEMI 1995, 2003 2 IP Address — Internet Protocol Address. A l ogical address which uniqu ely identifies a particular attachment to a TCP/IP network. local entity — relative to a particular end point of a …

100%1 / 7923
SEMI E37-0303 © SEM 1995, 2003 1
SEMI E37-0303
HIGH-SPEED SECS MESSAGE SERVICES (HSMS) GENERIC
SERVICES
NOTICE: The designation of SEMI E37 was updated during the 0303 publishing cycle to reflect the reapproval of
SEMI E37.2.
1 Purpose
HSMS provides a means for independent manufacturers
to produce implementations which can be connected
and interoperate without requiring specific knowledge
of one another.
HSMS is intended as an alternative to SEMI E4 (SECS-
I) for applications where higher speed communication
is needed or when a simple point-to-point topology is
insufficient. SEMI E4 (SECS-I) can still be used in
applications where these and other attributes of HSMS
are not required.
HSMS is also intended as an alternative to SEMI E13
(SECS Message Services) for applications where
TCP/IP is preferred over OSI.
It is intended that HSMS be supplemented by
subsidiary standards which further specify details of its
use or impose restrictions on its use in particular
application domains.
2 Scope
High-Speed SECS Message Services (HSMS) defines a
communication interface suitable for the exchange of
messages between computers in a semiconductor
factory.
3 Referenced Documents
3.1 SEMI Standards
SEMI E4 — SEMI Equipment Communication
Standard 1 — Message Transport (SECS-I)
SEMI E5 — SEMI Equipment Communication
Standard 2 — Message Content (SECS-II)
3.2 IETF Documents
1
IETF RFC 791 — Internet Protocol
IETF RFC 792 — Internet Control Message Protocol
IETF RFC 793 — Transmission Control Protocol
IETF RFC 1120 — Requirements for Internet Hosts -
Communication Layers
1 The IETF documents can be obtained from The Network
Information Center, Network Solutions, 14700 Park Meadow Drive,
Suite 200, Chantilly, VA 22021 USA
IETF RFC 1340 — Assigned Numbers. Note: This
RFC supersedes RFC 820.
3.3 POSIX Document
2
IEEE POSIX P1003.12 — Protocol Independent
Interfaces (PII)
4 Terminology
API — Application Program Interface. In the case of
TCP/IP, a set of programming conventions used by an
application program to prepare for or invoke TCP/IP
capabilities.
communication failure — a failure in the
communication link resulting from a transition to the
NOT CONNECTED state from the SELECTED state.
(See Section 9.)
confirmed service (HSMS) — an HSMS service
requested by sending a message from the initiator to the
responding entity which requires that completion of the
service be indicated by a response message from the
responding entity to the initiator.
connection — a logical linkage established on a TCP/IP
LAN between two entities for the purposes of
exchanging messages.
control message — an HSMS message used for the
management of HSMS sessions between two entities.
data message — an HSMS message used for
communication of application-specific data within an
HSMS session. A Data Message can be a Primary
Message or a Reply Message.
entity — an application program associated with an
endpoint of a TCP/IP connection.
header — a 10-byte data element preceding every
HSMS message.
initiator (HSMS) — the entity requesting an HSMS
service. The initiator requests the service by sending an
appropriate HSMS message.
2 POSIX documents can be obtained from Institute of Electrical and
Electronic Engineers (IEEE), 345 East 47th Street, New York, NY
10017 USA
SEMI E37-0303 © SEMI 1995, 2003 2
IP Address — Internet Protocol Address. A logical
address which uniquely identifies a particular
attachment to a TCP/IP network.
local entity — relative to a particular end point of a
connection, the local entity is that entity associated with
that endpoint.
local entity-specific — general qualifier to any
procedure, option, issue, or other implementation
matter which is not a subject of this standard and left to
the discretion of the individual supplier.
message — a complete unit of communication in one
direction. An HSMS Message consists of the Message
Length, Message Header, and the Message Text. An
HSMS Message can be a Data Message or a Control
Message.
message length — a 4-byte unsigned integer field
specifying the length of a message in bytes.
open transaction — a transaction in progress.
port — an endpoint of a TCP/IP connection whose
complete network address is specified by an IP Address
and TCP/IP Port number.
port number — (or TCP port number). The address of
a port within an attachment to a TCP/IP network which
can serve as an endpoint of a TCP/IP connection.
primary message — an HSMS Data Message with an
odd numbered Function. Also, the first message of a
data transaction.
published port — a TCP/IP IP Address and Port
number associated with a particular entity (server)
which that entity intends to use for receiving TCP/IP
connection requests. An entity' s published port must be
known by remote entities intending to initiate
connections.
receiver — the HSMS Entity receiving a message.
remote entity — relative to a particular endpoint of a
connection, the remote entity is the entity associated
with the opposite endpoint of the connection.
reply — an HSMS Data Message with an even-
numbered function. Also, the appropriate response to a
Primary HSMS Data Message.
responding entity (HSMS) — the provider of an HSMS
service. The responding entity receives a message from
an initiator requesting the service. In the event of a
confirmed service, the responding entity indicates
completion of the requested service by sending an
appropriate HSMS response message to the initiator of
the request. In an unconfirmed service, the responding
entity does not send a response message.
session — a relationship established between two
entities for the purpose of exchanging HSMS messages.
session entity — an entity participating in an HSMS
session.
session ID — a 16-bit unsigned integer which identifies
a particular session between particular session entities.
stream (TCP/IP) — a sequence of bytes presented at
one end of a TCP/IP connection for delivery to the
other end. TCP/IP guarantees that the delivered
sequence of bytes matches the presented stream.
HSMS subdivides a stream into blocks of contiguous
bytes - messages.
T3 — reply timeout in the HSMS protocol.
T5 — connect Separation Timeout in the HSMS
protocol used to prevent excessive TCP/IP connect
activity by providing a minimum time between the
breaking, by an entity, of a TCP/IP connection or a
failed attempt to establish one, and the attempt, by that
same entity, to initiate a new TCP/IP connection.
T6 — control Timeout in the HSMS protocol which
defines the maximum time an HSMS control
transaction can remain open before a communications
failure is considered to have occurred. A transaction is
considered open from the time the initiator sends the
required request message until the response message is
received.
T7 — connection Idle Timeout in the HSMS protocol
which defines the maximum amount of time which may
transpire between the formation of a TCP/IP connection
and the use of that connection for HSMS
communications before a communications failure is
considered to have occurred.
T8 — network Intercharacter Timeout in the HSMS
protocol which defines the maximum amount of time
which may transpire between the receipt of any two
successive bytes of a complete HSMS message before a
communications failure is considered to have occurred.
TCP/IP — Transmission Control Protocol/Internet
Protocol. A method of communications which provides
reliable, connection-oriented message exchange
between computers within a network.
TLI — Transport Level Interface. One particular API
provided by certain implementations of TCP/IP which
provides a transport protocol and operating system
independent definition of the use of any Transport
Level protocol.
transaction — a Primary Message and its associated
Reply message, if required. Also, an HSMS Control
Message of the request (.req) type, and its response
Control Message (.rsp), if required.
SEMI E37-0303 © SEM 1995, 2003 3
unconfirmed service (HSMS) — an HSMS service
requested by sending a message from the initiator to the
responding entity which requires no indication of
completion from the responding entity.
5 HSMS Overview and State Diagram
High-Speed SECS Message Services (HSMS) defines a
communication interface suitable for the exchange of
messages between computers in a semiconductor
factory using a TCP/IP environment. HSMS uses
TCP/IP stream support, which provides reliable two
way simultaneous transmision of streams of contiguous
bytes. It can be used as a replacement for SECS-I
communication as well as other more advanced
communications environments.
The procedure for HSMS communications parallels the
more familiar SECS-I communications it replaces. The
following steps are followed for any communications
(HSMS or otherwise):
1. Obtain a communications link between two
entities. In SECS-I, this is the RS232 wire
physically connecting host and equipment. In
HSMS, the link is a TCP/IP connection obtained by
the standard TCP/IP connect procedure. Note that
the abstract term “entity” is used instead of “host”
or “equipment.” This is because, while HSMS is
used for SECS-I replacement, it has more general
applications as well. In a SECS-I replacement
application, the “host” is an “entity” and the
“equipment” is an “entity.”
2. Establish the application protocol conventions to
be used for exchanging data messages between two
entities. For SECS-I, this step is implicit in the fact
that semiconductor equipment is physically
connected on the two ends of the wire: the protocol
is SECS-II.
In the case of HSMS, the communications link is a
dynamically established TCP/IP connection on a
physical link which may be shared with many other
TCP/IP connections using protocols other than
HSMS or connections using non TCP/IP protocols.
HSMS adds a message exchange (called the Select
procedure) which is used to confirm to both entities
that the particular TCP/IP connection is to be used
exlusively for HSMS communications.
3. Exchange Data. This is the normal intended
purpose of the communications link. In both
SECS-I and HSMS, the procedure is to exchange
SECS-II encoded messages for the control of
semiconductor equipment and/or processes. Data
exchange normally continues until one or both of
the entities are taken off-line for equipment-
specific purposes, such as maintenance.
4. Formally end communications. In SECS-I, there is
no formal requirement here; the equipment to be
taken off-line stops communicating.
In HSMS, a message exchange (either the
“bilateral” Deselect procedure or the “unilateral”
separate procedure) is used for both parties to
confirm that the TCP/IP connection is no longer
needed for HSMS communications.
5. Break the communications link. In SECS-I, this is
done by physically unplugging the host or
equipment from the communications cable, which
only occurs during repair or physical
reconfiguration of the factory network
environment.
In HSMS, since it uses the dynamic connection
environment of TCP/IP, the TCP/IP connection is
logically broken via a release or a disconnect
procedure without any physical disconnect from
the network medium.
Two additional procedures, of a diagnostic nature, are
supported in HSMS, which are generally not required
by a simple SECS-I link or a SECS-I direct
replacement. These follow:
1. Linktest. This procedure provides a simple
confirmation of connection integrity.
2. Reject. Because HSMS is intended to be extended
to protocols other than just SECS-II (by means of
subsidiary standards), it is possible that two entities
can be connected (due to a configuration error)
which use incompatible subsidiary standards. Also,
during initial implementation, incorrect message
types may be sent, or they may be sent out of order
due to software bugs. The reject procedure is used
to indicate such an occurrence.
5.1 HSMS Connection State Diagram — The HSMS
state machine is illustrated in the diagram below. The
behavior described in this diagram defines the basic
requirements of HSMS: subsidiary standards may
further extend these or other states.