开发工具:
文件大小: 1mb
下载次数: 0
上传时间: 2019-07-27
详细说明：SEIM E4 E5 半导体数据采集资料 通讯协议资料 设备联网 智能制造基础资料sem‖"
I The seMi equipment Communications Standard Part 2(SECS-In defines the details of the interpretation of
messages exchanged between intelligent equipment and a host. This specificalion has been developed in cooperation
with the Japan Electronic Industry Development Association Committee 12 on Equipment Communications
the message trans fer protocol requirements are contained in po E v
1. 1. 1 It is the intent of this standard to be fully compatible with SEMI E4- Equipment Communications Standard
(SECS-I). It is also the intent to allow for compatibility with alt
rnative message transfer protocols. The details of
1. 1. 2 It is the intent of this standard to define messages to such a level of detail that some consistent host software
may be constructed with only minimal knowledge of individual equipment. The equipment, in turn, may b
constructed with only minimal knowledge of the host
1.1.3 The messages defined in the standard support the most typical activities required for IC manufacturing. The
standard also provides for the definition of equipment-specific messages to support those activities not covered by
the standard messages. While certain activities can be handled by common software in the host, it is expected that
equipment-specific host software may be required to support the full capabilities of the equipment
2. 1 SECS-II gives form and meaning to messages exchanged between equipment and host using a message transfer
protocol, such as SECS-T
2.1.1 SECS-iI defines the method of conveying information between equipment and host in the form of messages
These messages are organized into categories of activities, called streams, which contain specific messages, called
functions. A request for information and the corresponding data transmission is an example of such an activity
2.1.2 SECS-il defines the structure of messages into entities called items and lists of items. This structure allows for
a self-describing data format to guarantee proper interpretation of the message
2. 1. 3 The interchange of messages is governed by a set of rules for handling messages called the transaction
protocol. The transaction protocol places some minimum requirements on any SECS-ll implementation
This standard does not purport to address safety issues, if any, associated with its use. It is the
responsibility of the users of this standard to establish appropriate safety and health practices and determine the
applicability of regulatory or other limitations prior to use
I SECS-II applies to equipment and hosts used in the manufacturing of semiconductor devices. Examples of the
activities supported by the standard are: transfer of control programs, material movement information, measurement
data summarized test data, and alarms
3. 1. 1 The minimum compliance to this standard involves meeting the few constraints outlined in$ 8. It is expected
that a given piece of equipment will require only a subset of the functions described in this standard. The number of
functions and the selection of functions will depend upon the equipment capabilities and requirements. For each
piece of equipment, the exact format for each function provided must be documented according to the form outlined
n§10.
3. 1.2 It is assumed that the equipment will define the messages used in a particular implementation of sECs-I. It is
assumed the host will support equipment implementation
4.1
SEMI E4- SEMI Equipment Communications Standard 1 Message Transfer(SECS-I)
SEMI E6
uide for Semiconductor equipment Installation Documentation
SEMI E148- Specification for Time Sychronization and Definition of the TS-Clock Object
sem‖"
4.2
ANSI X3.4-1977-Code for Information Interchange(ASCID
4.3
ieEE 754- Standard for binary Floating Point Arithmetic
4. 4 The Japan Electronic Industry Development Association (JEIDA) has requested that the sECs-ll standard
incorporate support for the Jis-8 codes for data exchange. This code would allow support for katakana characters in
Japanese implementations of SECS-II
JIS-6226-JIS 8-bit Coded Character Set for Information Interchange, Japanese Industrial Standards. 3
Unless otherwise indicated, all documents cited shall be the latest published versions
5.1.1 The following brief definitions refer to sections providing further information
5.1.2
-a physical division of a message used by the message transfer protocol(see 86.3)
5.1.3
a sequence of related messages(see884
5.1.4
an indication that a conversation has not completed properly(see$8.4.1)
a number between 0 and 32767 used in identifying the particular piece of equipment
communicating with a host(see$6.4.1)
5.1.6
the intelligent system which communicates with a host.
5.1.7
a specific message for a specific activity within a stream(see 87.2)
5.1.8
the intelligent system which communicates with the equipment
5.1.9
-the system that interprets a primary message and generates a reply when requested(see$ 6.2)
5.1.10
-a data element within a message(see$9.2)
5.1.11
a code used to identify the data type of an item(see$9.2)
5.1.12
a group of items(see$9.3
5.1.13
-a complete unit of communication(see 86.2)
5.1.14
information about the message passed by the message transfer protocol (see$ 6. 4)
5.1.15
a message sent in more than one block by the message transfer protocol(see $ 6.3.2)
- the creator of a primary message(see $6.2)
5.1.17
-a physical division of a message used by the message transfer protocol (see $ 6.3)
5.1.18
an odd numbered message. A lso, the first message of a transaction(see $6.2 and 7.2)
the particular secondary message corresponding to a primary message(see 86.2 and$ 7.2
5.1.20
an even-numbered message. Also the second message of a transaction(see$ 6.2 and
§7.2)
American National Standards Institute, Headquarters: 1819 1, Street, NW, Washington, DC 20036, USA. Telephone: 202.293.8020; Fax
202 293 9287, New York Office: 1 1 West 42nd Street, New York, NY 10036. USA. Telephone: 212.. 4900: Fax: 212.398.0023
httpi/www.ansl.org
2 Institule of Electrical and Electronics Engineers, IEEE Operalions Center, 445 Hoes Lane, P.O. Box 1331, Piscataway, New Jersey 08855
1331,usa.Telephone:732.981.0060;Fax:732.981.1721;http:/www.icee.org
3 Japanese Industrial Standards. Available through the Japanese Standards Associalion, 1-24, Akasaka 4-Choine, Minato-ku, Tokyo 107-8440
Japan.Telephone:81.3.3583.8005;Fax:81.3.3586.2014:http:/www.jsa.or.ip
sem‖"
5.1.21
-a message sent in one block by the message transfer protocol(see $6.3.1)
5.1.22
a category of messages(see$7.1)
5.1.23
a primary message and its associated secondary message, if any(see 88.2)
5.1.24
an indication from the message transfer protocol that a transaction has not completed
properly (see $6.5)
6.1
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
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 message at its destination and generates a reply when
requested
The message transfer protocol must support the follow ing SECS-II message blocking
requirements.
6.3.1
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-lI messages
6.3.2
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
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.
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
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
dentification
64.3
The message transfer protocol must be capable of identifying whether a reply is requested
to a primary message
6.5
It is presumed that the message transfer protocol will notify SECs-ll in the event of
failure to receive an expected reply message within a specified transaction timeout period
NOTE 2: In SECS-L, 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 interblock timeout (T4)is exceeded before an expected block of a multi-block message is received
sem‖"
6.6
This standard allows, but does not require, the support of more than one
concurrent open transaction
7.1
-A stream is a category of messages intended to support similar or related activities
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 delermined 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$ 10.4
7.3
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 O
7.3.1 The stream and function codes available for user definition are as follows
In Streams 1 63. Functions 64 255
In Streams 64127 Functions 1-255
7.3.2 The stream and function code assignment can also be represented by the diagram shown in Figure 1
7.3.3 The reserved codes assigned by this standard are listed in810. It is recognized that there will be user needs
definition should be used subject to the guidelines for minimum compliance outlined n e nctions reserved for user
beyond the specific definitions given in this standard. In these situations, the streams and fu
sem‖"
8.1
For an implementation to be in compliance with secs-il. it must meet the minimum transaction
requirements outlined in this section. The conversation protocols serve to further define the use and interaction
between transactions
A transaction forms the basis for all information exchanges in SECS-I. 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
The following are the requirements to comply with the SECS-ll protocol at
the transaction level
1. Respond to Sl, Fl with S1, F2 as described in8 10.5
Stream 9. As described in S 10.13, S9, F1, F3, F5, F7, or F1l are posse Send the appropriate error message on
2. For any received Imessage that cannot be processed by the equipment,
3. Format any other supported messages according to$ 10
4. Upon detection of a transaction timeout at the equipment, send $9F9 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
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
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
It the equipment, S9, F13 should be sent to the host
84.2
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 acknow ledgment 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 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 $ 9, F13 error message to the originator note that under the
definition of $9, 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$ 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$ 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
sem‖"
ways:()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/acknow ledge/ 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 $9, 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 transactions do not
use these words
9.1
All information transmitted according to this standard will be formatted using two data structures,
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
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
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 delined in the detailed message definitions
9.2.2 Bits 3-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 o is called a list and is defined in$9.3. Format code 22
(octal) is called a localized string and is defined in$9. 4. The remaining 14 item formats define unspecified binary
code 10 (octal); Boolean, code ll(octal); ASCll character strings, code 20(octal); JIS-8 character strings, code 2
octal) signed integer, codes 30, 31, 32, 34(octal); floating point, codes 40, 44(octal); and unsigned integer, codes
50, 51, 52, 54(octal). These formats are used for groups of data which have the same representation in order to save
sem‖"
repeated item headers In signed integers, negative values will be twos complement values. Floating point numbers
will conform to the ieeE standard 754. Boolean values will be byte quantities, with zero being equivalent to false
and non-zero being equivalent to true
A list is an ordered set of elements, where an element can be either an item($9.2 )or a list. The list
header(lh) has the same form as an item header with format type 0. However, the length bytes refer to the number
of elements in the list rather than to the number of bytes. The list structure allows grouping items of related
information which may have different formats into a useful structure
9.3. 1 A zero-length in the format byte is illegal and produces an error. A zero-length in the list length bytes has a
special meaning, which is defined in the detailed message definitions
000000
LIST (length in clements)
001000
10
Binary
001001
Boolean
010000
20
ASCII
O1000l
JIS-8
010010
22
2 byte character 2, #4
011000
8 byte integer(signed)
0l1001
I byte integer(signed)
0l1010
2 byte integer(signed)
0l1100
34
4 byte integer(signed)
100000
40
8 byte floating point
100100
4 byte floating poim'3
101000
50
8 byte integer(unsigned
101001
I byte integer(unsigned)
101010
2 byte integer(unsigned)2
101100
4 byte integer(unsigned)
#1 Non-printing characters are equipment-specific
#2 Most significant b
#3 IEEE 754. The byte containing the sign bit is sent first
#4 The code for multi-byte character must be specified in the data in the first 2 bytes of
the teXt item
#5 Changes in integer format codes may conflict with earlier implementations
A localized character string is an ilen which is used for representing a
string of multi-byte characters. Because there are many different encoding schemes and the information could be in
any one of a number of languages, these characteristics must also be included in the item. Thus for localized
character strings which use item format code 22(octal), there is an additional localized string header (lsh)
9.4.1 This localized string header follows the item header and precedes the string. The localized string header is part
of the item data, thus the length of the header(2 bytes) is included in the length in the item header The length of the
localized string itself is the number of bytes that it occupies, regardless of the number of characters that represents
the string. The localized string header followed by the string together comprise the localized string item. For
example, a 2 byte localized string (which may represent a single character), because of the 2 byte length of the
localized string header, will have a 4 byte length in the item header
sem‖"
9.4.2 The LSH is a 16 bit number which specifies the encoding method used for the string. Defined values for the
coding are as
none
reserved
11010646cs2
Unicode 2.0
UTF-8
Transformation of Iso
10646UCS-2
ISO646-1991
ASCIL. 7-bit
ISO8859-1
ISo Latin-1. Western
ISo 8859-11(proposed)
Thai
TIS 620
Thai(will be supported by
ISO8859-11)
Is13194(19)
ISCII
Shift jis
apanese EUC-JP
10
Korean EUC-KR
Simplified Chinese GB
12
Simplified Chinese euc-CN
Traditional Chinese Big5
14
Traditional Chinese EUC-TV
9.4.3 Encoding Codes from 15-32767 are reserved for future expansion. Encoding codes from 32768-65535 are
available for custom purposes
The data structures for different types of items are illustrated in the following
examples
An item contains one binary code 10101010
87654321
00100001
Item binary, 1 length byte
1 byte long
10101010
data byte
An item contains three ascii characters abc
01000001
Item ASCII, 1 length byte
00000011
Three bytes long
01000001
ASCII A
01000010
AsCI工B
01000011
AsC工工c
An item contains three binary numbers in 2-byte signed integer form
C1101001
Item 2-byte integers
C000110
6 bytes total (6/2=3 integers)
MSByte number x
XXXXXXXX
LSByte number x
yyyYYYYY
MSByte number y
YYYYYYY￥
LSByte number y
ZZZZZZZZ
MSByte number z
ZZZZZZZZ
LSByte number z
(系统自动生成,下载前可以参看下载内容)
下载文件列表
相关说明
- 本站资源为会员上传分享交流与学习,如有侵犯您的权益,请联系我们删除.
- 本站是交换下载平台，提供交流渠道，下载内容来自于网络，除下载问题外，其它问题请自行百度。
- 本站已设置防盗链，请勿用迅雷、QQ旋风等多线程下载软件下载资源，下载后用WinRAR最新版进行解压.
- 如果您发现内容无法下载，请稍后再次尝试；或者到消费记录里找到下载记录反馈给我们.
- 下载后发现下载的内容跟说明不相乎，请到消费记录里找到下载记录反馈给我们，经确认后退回积分.
- 如下载前有疑问，可以通过点击"提供者"的名字，查看对方的联系方式，联系对方咨询.
