semi合集-English.pdf - 第1605页

SEMI E37.1-0702 © SEMI 1995, 2002 6 RELATED INFORMATION 1 APPLICATION NOTES NOTE: This re lated information i s not an official part of SEMI E37.1 and i s not intended to m odify or superce de the official standard. Publ…

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

stem

(Resource-B)

Process Module B

(Resource-A)

Process Module

HSMS-SS

HOST

2 sessions

(2 device Ids)

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

Device ID -A

Device ID -B

Figure R1-1

R1-2 Multiple HSMS Connections

R1-2.1 Typically, an Equipment will accept only one Host Connection.

R1-2.2 A Host may connect to several units of Equipment, so the Host may have several simultaneously active

Connections (each to one Equipment).

R1-2.3 A Cell Controller (or similar entity) might have one Connection by which the Cell Controller appears as

“Equipment” to the Factory Host Computer, as well as several Connections by which the Cell Controller appears as

“Host” to Equipment.

R1-3 Equipment Support for Multiple Hosts

R1-3.1 HSMS requires Equipment to accept at least one active Connection, and does not require the equipment to

support access by multiple concurrent Hosts. That is, if the Equipment has already accepted a Host Connection, but

a Host (the same or a different Host) attempts a second Connection, the Equipment will immediately terminate that

second Connection attempt.

R1-3.2 For specialized applications, an equipment could accept more than one Host Connection. Coordination of

activity by multiple hosts is equipment-defined.

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.

International), 3081 Zanker Road, San Jose, CA 95134. Reproduction o

the contents in whole or in part is forbidden without express written

consent of SEMI.