semi合集-English.pdf - 第1062页

SEMI E5-1104 © SEMI 1982, 2004 4 message at its destinatio n and generates a repl y when requested. 6.3 Blocking Requirements — The message transfer protocol m ust support the foll owing SECS- II message blocking req uir…

100%1 / 7923
SEMI E5-1104 © SEMI 1982, 2004 3
katakana characters in Japanese implementations of
SECS-II.
JIS 8-bit Coded Character Set (JIS-6226) for
information Interchange, Japanese Industrial Standards.
3
NOTICE: Unless otherwise indicated, all documents
cited shall be the latest published versions.
5 Terminology
5.1 Definitions
5.1.1 The following brief definitions refer to sections
providing further information.
5.1.2 block — a physical division of a message used by
the message transfer protocol (see Section 6.3).
5.1.3 conversation — a sequence of related messages
(see Section 8.4).
5.1.4 conversation timeout — an indication that a
conversation has not completed properly (see Section
8.4.1).
5.1.5 device ID — a number between 0 and 32767 used
in identifying the particular piece of equipment
communicating with a host (see Section 6.4.1).
5.1.6 equipment — the intelligent system which
communicates with a host.
5.1.7 function — a specific message for a specific
activity within a stream (see Section 7.2).
5.1.8 host — the intelligent system which
communicates with the equipment.
5.1.9 interpreter — the system that interprets a primary
message and generates a reply when requested (see
Section 6.2).
5.1.10 item — a data element within a message (see
Section 9.2).
5.1.11 item format — a code used to identify the data
type of an item (see Section 9.2).
5.1.12 list — a group of items (see Section 9.3).
5.1.13 message — a complete unit of communication
(see Section 6.2).
5.1.14 message header — information about the
message passed by the message transfer protocol (see
Section 6.4).
3 Japanese Industrial Standards. Available through the Japanese
Standards Association, 1-24, Akasaka 4-Chome, Minato-ku, Tokyo
107-8440, Japan. Telephone: 81.3.3583.8005; Fax: 81.3.3586.2014.
Website: www.jsa.or.jp
5.1.15 multi-block message — a message sent in more
than one block by the message transfer protocol (see
Section 6.3.2).
5.1.16 originator — the creator of a primary message
(see Section 6.2).
5.1.17 packet — a physical division of a message used
by the message transfer protocol (see Section 6.3).
5.1.18 primary message — an odd numbered message.
Also, the first message of a transaction (see Sections
6.2 and 7.2).
5.1.19 reply — the particular secondary message
corresponding to a primary message (see Sections 6.2
and 7.2).
5.1.20 secondary message — an even-numbered
message. Also the second message of a transaction (see
Sections 6.2 and 7.2).
5.1.21 single-block message — a message sent in one
block by the message transfer protocol (see Section
6.3.1).
5.1.22 stream — a category of messages (see Section
7.1).
5.1.23 transaction — a primary message and its
associated secondary message, if any (see Section 8.2).
5.1.24 transaction timeout — an indication from the
message transfer protocol that a transaction has not
completed properly (see Section 6.5).
6 The Message Transfer Protocol
6.1 Intent — SECS-II is fully compatible with the
message transfer protocol defined by SECS-I. It is the
intent of this standard to allow for compatibility with
alternative message transfer protocols. The purpose of
this section is to define the requirements of the
interaction between an application using SECS-II and
the message transfer protocol. The methods used to
implement these requirements are not covered as a part
of this standard. The terms used in this standard are
those used by SECS-I. Equivalent terms may be
different for other message transfer protocols.
6.2 Messages — The message transfer protocol is used
to send messages between equipment and host. The
message transfer protocol must be capable of sending a
primary message, indicating whether a reply is
requested; and, if a reply is requested, it must be
capable of associating the corresponding secondary
message or reply message with the original primary
message. The term originator will refer to the creator
of the original primary message. The term interpreter
will refer to the entity that interprets the primary
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
0
1 6 3 6 4 1 27
1
63
64
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