semi合集-English.pdf - 第1587页

SEMI E37-0303 © SEM 1995, 2003 9 8.1 Gener al Message Forma t 8.1.1 Byte Structure — With in HSMS, a byte contains eight (8) bit s. The bits i n a byte are num bered from Bit 7 (most si gnificant) t o Bit 0 (least signif…

100%1 / 7923
SEMI E37-0303 © SEMI 1995, 2003 8
7.5 Linktest Procedure — The Linktest is used to
determine the operational integrity of TCP/IP and
HSMS communications. Its use is valid anytime in the
CONNECTED state.
7.5.1 Initiator Procedure
1. The initiator of the Linktest procedure sends the
Linktest.req message to the responding entity.
2. If the initiator receives a Linktest.rsp within the T6
timeout, the Linktest is successfully completed.
3. If the T6 timeout expires in the initiator before
receipt of a Linktest.rsp, it is considered a
communications failure (see “Special
Considerations”).
7.5.2 Responding Entity Procedure
1. The responding entity receives the Linktest.req
from the initiator.
2. The responding entity sends a Linktest.rsp.
7.6 Separate Procedure — The Separate procedure is
used to abruptly terminate HSMS communication for
an entity prior to breaking the TCP/IP Connection.
HSMS requires that the connection be in the
SELECTED state when using Separate. The responding
entity does not send a response and is required to
terminate communications regardless of its local state.
The procedure is as follows.
7.6.1 Initiator Procedure
1. The initiator of the select procedure sends the
Separate.req message to the responding entity. The
initiator' s Separate procedure completes
successfully. The NOT SELECTED state is entered
(see Section 5).
7.6.2 Responding Entity Procedure
1. The responding entity receives the Separate.req
from the initiator.
2. If the responding entity is in the SELECTED state,
its Separate procedure completes successfully.
3. If the responding entity is not in the SELECTED
state, the Separate.req is ignored.
7.7 Reject Procedure — The Reject procedure is used
in response to an otherwise valid HSMS message
received in an inappropriate context. Supporting the
reject procedure can provide useful diagnostic
information during the development of a distributed
application using HSMS. The procedure is as follows:
7.7.1 Initiator (Sender of Inappropriate Message)
Procedure
1. The initiator of the inappropriate message, upon
receiving the Reject.req, takes appropriate action
(local entity-specific).
7.7.2 Responding Entity Procedure
1. The entity receiving the inappropriate message
responds with a Reject.req message.
HSMS requires the reject procedure for the receipt of a
data message in the NOT SELECTED state, or the
receipt of a message whose SType or PType (see next
section: Message Format) is not defined for the entity
receiving the message. Subsidiary standards may define
other conditions which require the Reject Procedure. In
general, receipt of a reject message is an indication of
an improperly configured system or a software
programming error.
8 HSMS Message Format
This section defines the detailed format of the messages
used by the procedures in the previous section.
SEMI E37-0303 © SEM 1995, 2003 9
8.1 General Message Format
8.1.1 Byte Structure — Within HSMS, a byte contains
eight (8) bits. The bits in a byte are numbered from Bit
7 (most significant) to Bit 0 (least significant).
8.1.2 Message Format — An HSMS Message is
transmitted as a single contiguous stream of bytes in the
following order:
Table 2 HSMS Message Format
Number
of Bytes
Description
4 Bytes Message Length. MSB First. Specifies the
number of bytes in the Message Header plus the
Message Text.
10 Bytes Message Header.
0–n Bytes Message Text. Format is further specified by
PType field of message header.
8.1.3 Message Length — Message Length is a four-
byte unsigned integer value which specifies the length
in bytes of the Message Header plus the Message Text.
Message Length is transmitted most significant byte
(MSB) first and least significant byte (LSB) last.
The minimum possible Message Length is 10 (Header
only). The maximum possible Message Length is
implementation-specific.
8.1.4 Message Header — The Message Header is a ten-
byte field. The bytes in the header are numbered from
byte 0 (first byte transmitted) to byte 9 (last byte
transmitted). The format of the Message Header is as
follows:
Table 3 HSMS Message Header
Bytes Description
0–1 Session ID (Device ID)
2 Header Byte 2
3 Header Byte 3
4 PType
5 SType
6–9 System Bytes
The physical byte order is designed to correspond as
closely as possible to the SECS-I header.
8.1.4.1 Session ID — Session ID is a 16-bit unsigned
integer value, which occupies bytes 0 and 1 of the
header (byte 0 is MSB, 1 is LSB). Its purpose is to
provide an association by reference between control
messages (particularly Select and Deselect) and
subsequent data messages. It is the role of HSMS
subsidiary standards to specify this association further.
8.1.4.2 Header Byte 2 — This header byte is used in
different ways for different HSMS messages. For
Control Messages (see SType, below) it contains zero
or a status code. For a Data Message whose PType (see
below) = 0, it contains the W-Bit and SECS Stream.
For a Data Message with PType not equal to 0, see
“Special Considerations.”
8.1.4.3 Header Byte 3 — This header byte is used in
different ways for different HSMS messages. For
Control Messages, it contains zero or a status code. For
a Data Message whose PType (see below) = 0, it
contains the SECS Function. For a Data Message with
PType not equal to 0, see “Special Considerations.”
8.1.4.4 PType — PType (Presentation Type) is an 8-bit
unsigned integer value which occupies byte 4 of the
header. PType is intended as an enumerated type
defining the presentation layer message type: how the
Message Header and Message Text are encoded. Only
PType = 0 is defined by HSMS to mean SECS-II
message encoding. For non-zero PType values, see
“Special Considerations.”
Table 4 PType
Value Description
0 SECS-II Encoding
1–127 Reserved for subsidiary standards
128–255 Reserved, not used
8.1.4.5 SType — SType (Session Type) is a one-byte
unsigned integer value which occupies header byte 5.
SType is an enumerated type identifying whether this
message is an HSMS Data Message (value = 0) or one
of the HSMS Control Messages (other). Those values
not explicitly defined in the table are addressed in
“Special Considerations.”
SEMI E37-0303 © SEMI 1995, 2003 10
Table 5 SType
Value Description
0 Data Message
1 Select.req
2 Select.rsp
3 Deselect.req
4 Deselect.rsp
5 Linktest.req
6 Linktest.rsp
7 Reject.req
8 (not used)
9 Separate.req
10 (not used)
11–127 Reserved for subsidiary standards
128–255 Reserved, not used
8.1.4.6 System Bytes — System Bytes is a four-byte field occupying header bytes 6-9. System Bytes is used to
identify a transaction uniquely among the set of open transactions.
Uniqueness — The System Bytes of a Primary Data Message, Select.req, Deselect.req, or Linktest.req message must
be unique from those of all other currently open transactions initiated from the same end of the connection. They
must also be unique from those of the most recently completed transaction.
Reply Message — The System Bytes of a Reply Data Message must be the same as those of the corresponding
Primary Message. The System Bytes of a Select.rsp, Deselect.rsp, or Linktest.rsp must be the same as those of the
respective “.req” message.
8.2 HSMS Message Formats by Type — The specific interpretation of the header bytes in an HSMS message is
dependent on the specific HSMS message type as defined by the value of the SType field. The complete set of
messages defined is summarized in the table below, shown for PType = 0 (SECS-II message format).
Table 6 HSMS Message Format Summary
Message Header
Message Type
Bytes 0-1
SessionID
Byte 2
Byte 3
Byte 4
PType
Byte 5
SType
Bytes 6–9 System Bytes
Message Text
Data Message * W-bit and
SECS Stream
SECS
Function
0 0 Primary: UniqueReply:
Same as primary
Text
Select.req * 0 0 0 1 Unique none
Select.rsp Same as .req 0 Select
Status
0 2 Same as .req none
Deselect.req * 0 0 0 3 Unique none
Deselect.rsp Same as .req 0 Deselect
Status
0 4 Same as .req none
Linktest.req 0xFFFF 0 0 0 5 Unique none
Linktest.rsp 0xFFFF 0 0 0 6 Same as .req none
Reject.req same as message
being rejected
PType or
SType of
message
being rejected
Reason
Code
0 7 Same as message being
rejected
none
Separate.req * 0 0 0 9 Unique none
* Indicates further specification by subsidiary standards.