semi合集-English.pdf - 第1063页

SEMI E5-1104 © SEMI 1982, 2004 5 0 1 6 3 6 4 1 2 7 1 6 3 6 4 2 5 5 A v a i l a b l e f o r u s e r d e f i n i t i o n R e s e r v e d f o r t h i s s t a n d a r d Figure 1 Stream and Functi on Allocation 7.3.2 The rese…

SEMI E5-1104 © SEMI 1982, 2004 4

message at its destination and generates a reply when

requested.

6.3 Blocking Requirements — The message transfer

protocol must support the following SECS-II message

blocking requirements.

6.3.1 Single-Block Messages — SECS-II requires that

certain messages be sent in a single block or single

packet by the message transfer protocol. Those

messages defined in this standard as single-block

SECS-II messages must be sent in a single-block or

packet. The method used by the application software to

tell the message transfer protocol that a particular

message must be sent as a single block is not covered as

part of this standard. For compatibility with SECS-I,

the maximum length allowed for a single-block SECS-

II message is 244 bytes. The minimum requirement for

the message transfer protocol is to be able to send

single-block SECS-II messages.

6.3.2 Multi-Block Messages — For compatibility with

SECS-I, SECS-II messages that are longer than 244

bytes are referred to as multi-block messages. Also,

certain SECS-II messages are allowed to be multi-block

messages even if they otherwise meet the single-block

length requirements. Certain older implementations

may impose application-specific requirements on block

sizes for certain incoming messages. Beginning with

the 1988 revision of the standard, new applications may

not impose application-specific requirements on

incoming block sizes. Applications implemented

before 1988 may impose such requirements.

6.4 Message Header — The message transfer protocol

must provide the following information, called the

message header, with every message. Only the content

of the message header is defined by this standard. The

exact format of the message header passed between the

application and the message transfer protocol is not

covered as part of this standard.

NOTE 1: In SECS-I, this information is contained in the 10-

byte header of each block of a message.

6.4.1 Device ID — The message transfer protocol must

be capable of identifying the device ID (0–32767)

which indicates the source or destination of a message.

6.4.2 Stream and Function — The message transfer

protocol must be capable of identifying to SECS-II a

minimum15-bit message identification code. In SECS-

II, messages are identified by a stream code (0–127, 7

bits) and a function code (0–255, 8 bits). Each

combination of stream and function represents a distinct

message identification.

6.4.3 Reply Requested — The message transfer

protocol must be capable of identifying whether a reply

is requested to a primary message.

6.5 Transaction Timeout — It is presumed that the

message transfer protocol will notify SECS-II in the

event of failure to receive an expected reply message

within a specified transaction timeout period.

NOTE 2: In SECS-I, a transaction timeout occurs if either the

reply timeout (T3) is exceeded before the first block of a reply

message is received or if the inter-block timeout (T4) is

exceeded before an expected block of a multi-block message

is received.

6.6 Multiple Open Transactions — This standard

allows, but does not require, the support of more than

one concurrent open transaction.

7 Streams and Functions

7.1 Streams — A stream is a category of messages

intended to support similar or related activities.

7.2 Functions — A function is a specific message for a

specific activity within a stream. All the functions used

in SECS-II will follow a numbering convention

corresponding to primary and secondary message pairs.

All primary messages will be given an odd-numbered

function code. The reply message function code is

determined by adding one to the primary message

function code. The even-numbered function following

a primary message which requests no reply is reserved

and is not to be used. Function code 0 is reserved in all

streams for aborting transactions as described in

Section 10.4.

7.3 Stream and Function Allocation — Some of the

stream and function code combinations are reserved for

this standard, while others are available for user

definition. The stream and function codes reserved for

this standard are as follows:

In Stream 0, Functions 0–255.

In Streams 1–63, Functions 0–63.

In Streams 64–127, Function 0.

The stream and function codes available for user

definition are as follows:

In Streams 1–63, Functions 64–255.

In Streams 64–127, Functions 1–255.

7.3.1 The stream and function code assignment can

also be represented by the diagram shown in Figure 1.

SEMI E5-1104 © SEMI 1982, 2004 5

1 6 3 6 4 1 27

25 5

Ava ilable

for use r

definition

Re se rve d

for t his

st a nda rd

Figure 1

Stream and Function Allocation

7.3.2 The reserved codes assigned by this standard are

listed in Section 10. It is recognized that there will be

user needs beyond the specific definitions given in this

standard. In these situations, the streams and functions

reserved for user definition should be used subject to

the guidelines for minimum compliance outlined in

Section 8.

8 Transaction and Conversation Protocols

8.1 Intent — For an implementation to be in

compliance with SECS-II, it must meet the minimum

transaction requirements outlined in this section. The

conversation protocols serve to further define the use

and interaction between transactions.

8.2 Transaction Definition — A transaction forms the

basis for all information exchanges in SECS-II. A

transaction consists of either a primary message for

which no reply is requested, or a primary message

which requests a reply together with its corresponding

secondary message. Secondary messages cannot

request a reply.

8.3 Transaction Level Requirements — The following

are the requirements to comply with the SECS-II

protocol at the transaction level:

1. Respond to S1F1 with S1F2 as described in

Section 10.5.

2. For any received message that cannot be processed

by the equipment, send the appropriate error

message on Stream 9. As described in Section

10.13, S9F1, F3, F5, F7, or F11 are possible.

3. Format any other supported messages according to

Section 10.

4. Upon detection of a transaction timeout at the

equipment, send S9F9 to the host.

5. Upon receipt of function 0 as a reply to a primary

message, terminate the related transaction. No

error message should be sent to the host by the

equipment.

8.4 Conversation Protocols — A conversation is a

series of one or more related transactions used to

complete a specific task. A conversation should

include all transactions necessary to accomplish the

task and leave both the originator and interpreter free of

resource commitments at its conclusion.

8.4.1 Conversation Timeout — A conversation timeout

is used to indicate that a conversation has not

completed properly. A conversation timeout is

application-dependent, and the methods used for

detecting conversation timeouts are not covered as part

of this standard. A conversation timeout will terminate

further action on the conversation, and will allow for

the clearing of any committed resources. Upon

detection of a conversation timeout at the equipment,

S9F13 should be sent to the host.

8.4.2 Types of Conversations — There are seven types

of conversations which characterize all information

exchanges in SECS-II:

1. A primary message with no reply is the simplest

conversation. This message must be a single-block

SECS-II message. The originator must assume that

the interpreter responds to the message. This

conversation is used where the originator can do

nothing if the message is rejected.

2. If the interpreter has data that the originator wants,

the data are requested with a primary message and

the data returned to the originator as a reply

message. It is assumed that the originator

requesting the data is prepared to receive the

amount of data returned. This is the request/data

conversation.

3. If the originator wishes to send data in a single-

block SECS-II message to the interpreter, then the

originator sends the data and expects an

acknowledgment from the interpreter. This is the

send/acknowledge conversation.

4. If the originator has a multi-block SECS-II

message to send for a particular exchange, then the

originator must receive permission from the

interpreter prior to sending the data. The first

transaction requests permission to send, and the

interpreter either grants or denies permission. If

SEMI E5-1104 © SEMI 1982, 2004 6

permission is granted, the originator sends the data

and the interpreter replies appropriately. This is

the inquire/grant/send/acknowledge conversation.

Between the inquire and the send, the interpreter

may commit some resources in preparation for the

data. Consequently, a conversation timeout may be

set by the interpreter at a time dependent upon the

application, at which time the interpreter will free

its resources and send an S9,F13 error message to

the originator. Note that under the definition of

S9,F13 in this standard, only the equipment should

generate an error message to the host under these

conditions.

5. There is a conversation related to the transfer of

unformatted data sets between equipment and host.

This conversation is described in detail in Stream

13. (See Section 10.17)

6. There is a conversation related to the handling of

material between equipment. This conversation is

described in detail in Stream 4. (See Section 10.8)

7. The originator may request information from the

interpreter which requires some time to obtain

(e.g., operator input is required). The first

transaction requests the information and the

interpreter responds in one of three ways: 1) the

information is returned, 2) the interpreter indicates

that the information cannot or will not be obtained,

or 3) the interpreter indicates that the information

will be obtained and returned in a subsequent

transaction, as specified for this conversation. For

case number 3, the interpreter will initiate the

subsequent transaction when the information is

available.

8.4.2.1 Case 3 is the request/acknowledge/send/

acknowledge transaction.

8.4.2.2 The originator of the request/acknowledge/

send/acknowledge conversation may commit some

resources in anticipation of the send/acknowledge

transaction. Consequently, a conversation timeout may

be set by the originator at a time dependent on the

application. On timeout, the originator will free its

resources and restart the conversation with the

‘request’, or send an S9,F13 error message. Note that

under the definition of S9,F13 in this standard, only the

equipment should generate an error message to the host

under these conditions.

8.4.3 The key words, request, data, send, acknowledge,

inquire, and grant are used in the function names as an

aid to understanding the relationship between the

messages and the conversation. Single message trans-

actions do not use these words.

9 Data Structures

9.1 Intent — All information transmitted according to

this standard will be formatted using two data struc-

tures, items and lists. These data structures define the

logical divisions of the message, as distinct from the

physical divisions of the message transfer protocol.

They are intended to provide a self-describing internal

structure to messages passed between equipment and

host.

9.2 Item — An item is an information packet which

has a length and format defined by the first 2, 3, or 4

bytes of the item. These first bytes are called the item

header (IH). The item header consists of the format

byte and the length byte(s) as shown in Figure 2. Bits

one and two of the item header tell how many of the

following bytes refer to the length of the item. This

feature allows for long items without requiring the byte

overhead for shorter items. The item length refers to

the number of bytes following the item header, called

the item body (IB), which is the actual data of the item.

The item length refers only to the item body not

including the item header, so the actual number of bytes

in the message for one item is the item length plus 2, 3,

or 4 bytes for the item header. All bytes in the item

body are in the format specified in the format byte.

No. of

len

th b

tes

item format code

len

length

MSB

LSB

8 7 6 5 4 3 2 1 bit

MS b

LS b

{

Format

Length

tes

No. of Length bytes

0 = Illegal, data format error

1 = One binary length byte (max = 255)

2 = Two binary length bytes (max = 64k)

3 = Three binary length bytes (max = 7.99M)

Length refers to the number of bytes except in a list format where it

refers to the number of elements

(

items or lists

)

in the list.

Figure 2

Item and List Header

9.2.1 A zero-length in the format byte is illegal and

produces an error. A zero-length in the item length

bytes has a special meaning as defined in the detailed

message definitions.

9.2.2 Bits 3 through 8 of the format byte of the item

header define the format of the data which follows. Of

the 64 possible formats, 16 are defined as shown in

Table 1. Format code 0 is called a list and is defined in

Section 9.3. Format code 22 (octal) is called a localized

string and is defined in Section 9.4. The remaining 14

item formats define unspecified binary, code 10 (octal);

Boolean, code 11 (octal); ASCII character strings, code

20 (octal); JIS-8 character strings, code 21 (octal)