semi合集-English.pdf - 第1598页

SEMI E37-0303 © SEMI 1995, 2003 20 A1-7 TCP/IP Physical Layer HSMS does not specify the physical layer of IP. Any physical laye r supported by TCP/IP can be used. Most commonly , TCP/IP implementations use Ethernet (IEEE…

SEMI E37-0303 © SEM 1995, 2003 19

A1-3 HSMS Alternating Mode Connect

Procedure

Some users have particular requirements which prevent

them from determining which connect mode (active or

passive) a given entity will use at any particular time. In

such a case, a Local Entity alternately attempts the

active mode and passive mode connect procedure until

a connection is successfully established. Note that this

requires that local entity provide a published port when

in the passive phase. The general logic sequence at the

Alternating Local Entity is as follows:

1. Attempt an active connect procedure as described

in Section 6.3.3 using a timeout value for the

t_rcvconnect greater than or equal to the

connection separation timeout T5.

2. If the active connect procedure completes

successfully, the alternating mode connect

procedure completes successfully.

3. If the active connect procedure terminates

unsuccessfully, attempt the passive connect

procedure as described in 6.3.2 with the timeout for

the t_listen greater than or equal to the connection

separation timeout T5.

4. If the passive connect procedure completes

successfully, the alternating mode connect

procedure completes successfully as described in

6.3.2.

5. If the passive connect procedure terminates

unsuccessfully, the local entity may either return to

step 1 to continue the alternating mode procedure

or terminate unsuccessfully. The number of times

the above sequence of steps are repeated in

attempting to form a connection is a local entity-

specific issue.

A1-3.1 Alternating Mode Cycle Time — The

Alternating Mode Cycle Time is the time between

iterations of the Connect Procedure of an Alternating

Mode entity. In the above procedure, this corresponds

to the duration between the initiation of step 1 and

completion of step 5 immediately prior to the

reinitiation of step 1. This time is implementation-

dependent.

In the case that two entities are both using the

Alternating Mode Connect Procedure, it is desirable to

ensure that they both have different alternating mode

cycle times, to prevent the entities from attempting to

connect in lock step: both in active mode, then both in

passive mode. Adjusting the Alternating Mode Cycle

Time can be readily achieved by adjustment of T5 so

that the cycle time is different for the two entities:

A1-3.2 HSMS Connect Combinations — An entity

configured as alternating between active and passive

mode can connect with either an passive or active mode

remote entity. The list below summarizes the

combinations possible using the standard with this

particular connections strategy.

1. An Entity “A” configured as ACTIVE can connect

to an Entity “B” configured as PASSIVE or as

ALTERNATING, and Entity A always establishes

the Connection.

2. An Entity “A” configured as ALTERNATING can

connect to an Entity “B” configured as PASSIVE,

and Entity “A” always establishes the Connection.

3. An Entity “A” configured as ALTERNATING can

connect to an Entity “B” configured as

ALTERNATING, and either end can establish the

Connection. In implementations which use multi-

threaded connect logic, rather than the sequential

logic described in this document, it may be

possible that both ends of the HSMS connection

attempt to connect at the same time. In this case,

there can be two separate TCP/IP connections

established, and it is necessary to establish a

convention so that one connection is allowed to

remain and the other is terminated.

4. It is not allowed to connect two Entities both

configured as PASSIVE, or both configured as

ACTIVE.

A1-4 Non-HSMS TCP/IP Protocols

For typical TCP/IP implementations, HSMS can co-

exist with other TCP/IP based protocols on the same IP

Address. This can be very useful. For example, a

SECS-II message transaction could trigger an

application to begin a TCP/IP FTP (File Transfer

Protocol) sequence to transfer a large data file.

A1-5 Non-TCP/IP Protocols

The use of protocols other than TCP/IP on the same

network as the HSMS entities is possible but beyond

the scope of this standard. Typically, other protocols

could be used, provided they have no impact on TCP/IP

or HSMS entities on the network.

A1-6 Multiple LANs

The HSMS specification considers only a single

TCP/IP LAN. Interconnecting multiple LANs is outside

the scope of HSMS. However, since TCP/IP

implementations typically support such configurations

seamlessly through gateways, routers, and similar

entities, it may be possible to establish an HSMS

Connection across interconnected LAN’s.

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.

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.

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.