semi合集-English.pdf - 第1604页

SEMI E37.1-0702 © SEMI 1995, 2002 5 7.5 Reject Procedure — The Reject Proced ure is optional in HSMS comm unications. Note, however , that any situation which wou ld require the use of the Reject as described in HSMS Gen…

100%1 / 7923
SEMI E37.1-0702 © SEMI 1995, 2002 4
# Old State New State Trigger Actions
5 HSMS
SELECTED
TCP/IP NOT
CONNECTED
HSMS Connection Terminates:
1. Decide to terminate and send
Separate.req; or
2. Receive Separate.req; or
3. T6 timeout waiting for
Linktest.rsp; or
4. Receive HSMS message length <
10; or
5. Receive HSMS message length >
maximum supported by entity; or
6. Receive bad HSMS message
header; or
7. T8 timeout waiting for TCP/IP; or
8. Other uncorrectable TCP/IP Error
(entity-specific).
1. Close TCP/IP connection.
6 HSMS
SELECTED
HSMS
SELECTED
T3 Timeout waiting for Data Reply
Message.
1. Cancel the Data Transaction as
appropriate (entry-specific) but do
not terminate the TCP/IP
connection; and
2. If entity is EQUIPMENT, send
SECS-II S9F9.
Table 3 When HSMS Transactions are Allowed
HSMS Transition
Allowed in State(s)
Who Initiates
Transaction?
Select HSMS Not
Selected
Active Entity
Link Test HSMS Selected Either Entity
Data HSMS Selected Either Entity
Separate HSMS Selected Either Entity
6 HSMS-SS Use of TCP/IP
6.1 As defined in HSMS.
7 HSMS-SS Procedures
7.1 Select Procedure — The Select Procedure shall only be initiated by the entity establishing the TCP/IP
connection in active mode. The Passive Mode Entity shall not initiate the Select Procedure.
7.1.1 The Select Procedure is only permitted in the NOT SELECTED state. It uses a SessionID value of 0xFFFF
and implies that all device IDs are available for communication. Immediately following any Select Procedure which
fails to complete successfully with a zero Select Status, each Entity must close the TCP/IP connection and transit to
the NOT CONNECTED state.
7.2 Data Procedure — The Data Procedure is as defined in HSMS Generic Services. Note that any SessionID value
that corresponds with a DeviceID supported by the Local Entity is valid as long as the Local Entity is in the
SELECTED state.
7.3 Deselect Procedure — Deselect shall not be used in an HSMS-SS implementation. Communication is ended
using the Separate Procedure.
7.4 Linktest Procedure — As defined by HSMS. Under HSMS-SS, the use of Linktest is strictly limited to the
SELECTED state.
SEMI E37.1-0702 © SEMI 1995, 2002 5
7.5 Reject Procedure — The Reject Procedure is
optional in HSMS communications. Note, however,
that any situation which would require the use of the
Reject as described in HSMS Generic Services shall be
treated as a communications failure in implementations
not supporting reject. Specifically, the TCP/IP
connection is immediately closed.
7.6 Separate Procedure — Separate shall always use
SessionID 0xFFFF (binary, all ones). In HSMS-SS, the
Separate.req is valid only in the TCP/IP CONNECTED
state and its substates. After either initiating or
receiving a Separate.req message, the entity shall
immediately close the TCP/IP connection and transit to
the TCP/IP NOT CONNECTED state.
7.7 Communications Failures — As defined by HSMS.
Note that, in addition to the communications failures
defined under HSMS, any violation of the restrictions
defined in prior sections of this document are also to be
treated as communication failures.
8 HSMS-SS Message Format
8.1 Session ID — In HSMS-SS Data Messages, the
high-order bit of Session ID is zero, and the low-order
15 bits contain Device ID, a 15-bit unsigned integer
value, which occupies the low-order 7 bits (bits 6-0) of
byte 0 and all of byte 1 of the header. Device ID is a
property of the equipment, and can be viewed as a
logical identifier associated with a physical device or
sub-entity within the equipment. The precise meaning
of “device” or “sub-entity” is equipment-defined. A
unit of equipment must have at least one Device ID.
Equipment which contains several devices may define a
unique Device ID for each device.
In HSMS-SS Control Messages, Session ID will always
assume the special value 0xFFFF (all one bits).
8.2 PType — All HSMS-SS messages are PType 0
(SECS II encoded) as defined in HSMS.
8.3 SType — Only HSMS-defined STypes are
permitted in HSMS-SS. User-defined SType messages
are not permitted.
9 Special Considerations
9.1 Multiblock Messages — For each SECS-II
message, the SECS-II standard defines whether that
message should be transmitted in SECS-I as a single-
block message or as a multiblock message.
This distinction becomes unimportant with HSMS,
which transmits all messages in the same fashion.
However, to be compatible with older SECS-I
applications, when an HSMS application sends a SECS-
II message defined as single block, the HSMS Message
Length should not exceed 254 bytes (10 byte header
plus 244 text bytes).
10 HSMS-SS Documentation
10.1 An HSMS-SS implementation is required to
document the following information in addition to the
information required by HSMS.
1. The number of deviceIDs supported and their
specific values.
2. Whether or not the implementation supports the
normal or the restricted procedure for terminating
communications.
3. The setting of the host vs. equipment parameter.
10.2 Host vs. Equipment — Many applications using
SECS-II will need to designate one end of the
communication link as “Equipment” and the other end
as “Host.” HSMS-SS itself does not require configuring
of “Host” and “Equipment,” but this parameter may be
included in configuration where needed. HSMS can
also be used in applications where the distinction
between Host and Equipment is not used.
NOTICE: 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.
SEMI E37.1-0702 © SEMI 1995, 2002 6
RELATED INFORMATION 1
APPLICATION NOTES
NOTE: This related information is not an official part of SEMI E37.1 and is not intended to modify or supercede the
official standard. Publication was authorized by full letter ballot. Determination of the suitability of the material is
solely the responsiblity of the user.
R1-1
R1-1.1 An entity may have more than one session. If a unit of equipment can be divided into two or more logical
sub-equipments, such as process chambers, or process resources, each of these may have separated session ID. If
two or more physical sub-equipments are controlled by an equipment controller or communicated to through a
TCP/IP network device, each sub-equipment may have a separate session ID. Such a session can be established
once HSMS is selected. Each session ID corresponds to a device ID.
R1-1.2 If a unit of equipment has more than one sub-equipment or process resource (e.g. process modules) but the
sub-equipment share a common resource (e.g. transfer subsystem), it is not recommended that each sub-equipment
have an independent session to communicate with host. Even if the host requests an action to the shared subsystem
with a session identifier specific for a sub-equipment, the shared subsystem may not always serve for the sub-
equipment. Since the host expects the shared subsystem to perform the service for the sub-equipment, an error will
occur if it is not possible to perform the service for the designated sub-equipment. See following figure.
(Resource-C)
Transfer Subsystem
(Resource-B)
Process Module B
(Resource-A)
Process Module A
HSMS-SS
HOST
common 1 session
(one device ID)
(Resource-C)
Transfer Subs
y
stem
(Resource-B)
Process Module B
(Resource-A)
Process Module
A
HSMS-SS
HOST
2 sessions
(2 device Ids)
T
yp
ical Case
Problematic Case:
Equipment may not know for which module a cassette is
sent. Because subsystem doesn’t have its own device ID,
arrival event may be reported with wrong device ID.
(Resource-D)
Transfer Subsystem D
(Resource-B)
Process Module B
(Resource-A)
Process Module A
HSMS-SS
HOST
2 sessions
(2 device Ids)
(Resource-C)
Transfer Subsystem C
Possible Case,
not intended
Equipment Controller
Equipment Controller
Equipment Controller
Device ID -A
Device ID -A
Device ID -B
Device ID -B
Figure R1-1