semi合集-English.pdf - 第1599页
SEMI E37-0303 © SEM 1995, 2003 21 Feature SECS-I HSMS Header Ten-byte header on each block of a message. Header bytes 4-5 contains E-Bit and Block Number. One ten-byte Header for th e entire message. Header bytes 4–5 con…
SEMI E37-0303 © SEMI 1995, 2003 20
A1-7 TCP/IP Physical Layer
HSMS does not specify the physical layer of IP. Any
physical layer supported by TCP/IP can be used. Most
commonly, TCP/IP implementations use Ethernet
(IEEE 802.3) as the physical layer. However, some
TCP/IP implementations use other protocols (e.g.,
Token Bus, IEEE 802.4 and .5). To ensure
interoperability within a given installation, it may be
desirable to establish additional local standards for the
physical layer.
A1-8 Well-Known TCP/IP Port Numbers
Some TCP/IP-based protocols specify a particular
“Well Known” TCP Port Number, which is published
and is not available for other protocols. HSMS does not
specify a particular “Well Known” TCP Port Number,
but instead requires that it be configurable. The IETF
defines “Assigned Well Known Port Numbers” in RFC
1340.
A1-9 Delay between Disconnect and Re-
Connect
Some TCP/IP systems exhibit problems with
applications which terminate a connection and then
quickly re-connect, when using identical TCP ports on
both ends of the connection. When using such systems,
it may be advisable to delay after disconnect before re-
connecting. The delay time varies among TCP/IP
implementations, but typically can be calculated as
twice the “Maximum Segment Lifetime” or MSL. For
example, most TCP/IP systems based on BSD (e.g.,
Sun, AIX) use a MSL of 30 seconds, so a delay of 60
seconds would be appropriate. If rapid connects are
required, your application should use a different Port, if
allowed by the Connect Mode you are using. In some
TCP/IP systems, this problem does not occur.
A1-10 User-Defined Message Types
It is recognized that equipment suppliers may find it
desirable to develop additional features not found in the
base level HSMS or any defined subsidiary standards.
This will be the case during the testing and
development of any proposed new subsidiary standard.
User-defined extensions through new message types are
permissible as long as they are confined to intra-vendor
communication interfaces: any inter-vendor
communications interface which requires the use of
such extensions is considered to be noncompliant with
the HSMS standard.
If a supplier does deem it necessary to extend or
otherwise go outside the standard, the use of “reserved,
not used,” values of PType and SType may simplify
their implementation by permitting the reuse of the
HSMS implementation rather than the implementation
and use of a completely separate parallel standard. By
remaining within the “reserved, not used,” ranges for
SType and PType, the implementor can be assured that
future subsidiary standards which define new values for
SType and/or PType will not conflict with user-defined
extensions.
A1-11 Comparison of SECS-I and HSMS
The following table compares major features of SECS-I
and HSMS.
Feature SECS-I HSMS
Communications Protocol
Base
RS-232 TCP/IP
Physical Layer 25-pin connector and 4-wire serial cable Physical layer not defined. HSMS allows any
TCP/IP supported physical medium. Typical
example is Ethernet (IEEE 802.3) and thin coax (10-
BASE-2).
Communications Speed Typically about 1000 bytes/second (assuming
9600 baud).
Typically 10 MBits/second (assuming typical
Ethernet).
Connections One physical RS-232 cable per SECS-I
connection.
One physical network cable can support many
HSMS Connections.
Message Format Message text is SECS-II Data Items.
Transmits a SECS-II message as a series of
transmittal blocks each approximately 256
bytes in size. Each block has a one-byte block
length, a ten-byte Block Header, text, and a
two-byte Checksum.
Message Text is SECS-II Data Items.
Transmits a SECS-II message as a TCP/IP byte
stream. The message has a four-byte Message
Length, a ten-byte Message Header, and text. The
TCP/IP layer may impose blocking limits which
depend on the physical layer used, but this blocking
is transparent to the TCP/IP API and is outside the
scope of HSMS.
SEMI E37-0303 © SEM 1995, 2003 21
Feature SECS-I HSMS
Header Ten-byte header on each block of a message.
Header bytes 4-5 contains E-Bit and Block
Number.
One ten-byte Header for the entire message. Header
bytes 4–5 contain PType and SType. Header bytes
2–3 are W-Bit, Stream, and Function when SType =
0 (Data Message). For SType not equal to 0 (Control
Message), bytes 2–3 have other uses. No R-Bit.
Maximum message size Limited to approximately 7.9 million bytes
(32767 blocks times 244 text bytes per block).
Message size limited by 4-byte message length
(approximately 4 GBytes). Local implementation of
TCP/IP and HSMS may further limit this in practice.
Protocol Parameters
(Common)
T3 Reply Timeout Device ID T3 Reply Timeout Session ID (analogous to Device
ID).
Protocol Parameters
(SECS-I only)
Baud Rate
T1 Inter-Character Timeout
T2 Block Protocol Timeout
T4 Inter-Block Timeout
RTY Retry Count
Host/Equipment
Not used in HSMS. Corresponding issues addressed
by TCP/IP layers.
Protocol Parameters
(HSMS Only)
Not needed by SECS-I. IP Address and Port of Passive Entity.
T5 Connect Separation Timeout.
T6 Control Transaction Timeout.
T7 NOT SELECTED Timeout.
T8 Network Intercharacter Timeout.
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 E37.1-0702 © SEMI 1995, 2002 1
SEMI E37.1-0702
HIGH-SPEED SECS MESSAGE SERVICE SINGLE SELECTED-
SESSION MODE (HSMS-SS or HSMS-SSS)
This standard was technically approved by the Global Information and Control Committee and is the direct
responsibility of the Japan Information and Control Committee. Current edition approved by the Japan
Regional Standards Committee on April 26, 2002. Initially available at www.semi.org June 2002; to be
published July 2002. Originally published in 1995; previoulsy published in 1996.
1 Purpose
1.1 HSMS-SS provides a means for independent
manufacturers to produce implementations which can
be connected without requiring specific knowledge of
one another.
1.2 HSMS-SS is intended as an alternative to SEMI E4
(SECS-I) for applications where higher speed
communication is needed.
1.3 HSMS-SS is intended as an alternative to SEMI
E13 (SECS Message Services) for applications where
TCP/IP is preferred over OSI as a communications
basis.
2 Scope
2.1 High-Speed SECS Message Services Single-
Session Mode (HSMS-SS) is a subsidiary standard to
High-Speed SECS Message Services (HSMS) Generic
Services.
2.2 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.
3 Reference Standards
NOTE 1: Unless otherwise indicated, all documents cited
shall be the latest published versions.
3.1 SEMI Standards
SEMI E4 — SEMI Equipment Communication
Standard 1 Message Transfer (SECS-I)
SEMI E5 — SEMI Equipment Communication
Standard 2 Message Content (SECS-II)
SEMI E37 — High-Speed SECS Message Services
(HSMS) Generic Services
4 Terminology
4.1 Definitions
4.1.1 device ID — a 15-bit field in the message header
used to identify a subentity within the equipment.
4.2 In addition, all definitions for HSMS Generic
Services apply.
4.3 Note that the terms HSMS and HSMS generic
services both refer to the HSMS Generic Services
standard definition (SEMI E37).
5 HSMS-SS Overview and State Machine
5.1 This definition defines the HSMS-SS-specific use
of HSMS Generic Services suitable for applications
requiring a simple SECS-I replacement. The purpose of
this standard is to explicitly limit the capabilities of the
HSMS Generic Services to the minimum necessary for
this type of application. Specifically, HSMS imposes
the following limitations:
1. HSMS-SS eliminates the use of a number of HSMS
procedures. Deselect is not to be used to end HSMS-
SS communications (use Separate instead), and the
Reject procedure is optional.
2. HSMS-SS limits certain other procedures such as
Select to simplify operation for the specific case of
SECS-I replacement.
5.2 The remainder of this document describes these
limitations in more detail.
5.3 HSMS-SS State Machine — The HSMS-SS
behavior and state machine differ from that specified in
the HSMS Generic Services in the following ways:
1. The SelectionCounter defined in HSMS Generic
Services is not required.
2. Various transitions are defined differently as
illustrated in the HSMS-SS state machine illustrated
below.