semi合集-English.pdf - 第1061页
SEMI E5-1104 © SEMI 1982, 2004 3 katakana char acters in Japanese implem entations of SECS-II. JIS 8-bit Code d Character Set (JIS-622 6) for informati on Interchan g e, Japanese I ndustrial Standards. 3 NOTICE: Unless o…
SEMI E5-1104 © SEMI 1982, 2004 2
1 Purpose
1.1 The SEMI Equipment Communications Standard
Part 2 (SECS-II) defines the details of the interpretation
of messages exchanged between intelligent equipment
and a host. This specification has been developed in
cooperation with the Japan Electronic Industry
Development Association Committee 12 on Equipment
Communications.
1.1.1 It is the intent of this standard to be fully
compatible with SEMI Equipment Communications
Standard E4 (SECS-I). It is also the intent to allow for
compatibility with alternative message transfer
protocols. The details of the message transfer protocol
requirements are contained in Section 6.
1.1.2 It is the intent of this standard to define messages
to such a level of detail that some consistent host soft-
ware may be constructed with only minimal knowledge
of individual equipment. The equipment, in turn, may
be 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 equip-
ment-specific messages to support those activities not
covered by the standard messages. While certain activ-
ities 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 Scope
2.1 SECS-II gives form and meaning to messages
exchanged between equipment and host using a
message transfer protocol, such as SECS-I.
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-II 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 mini-
mum requirements on any SECS-II implementation.
NOTICE: 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.
3 Limitations
3.1 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 Section
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 docu-
mented according to the form outlined in Section 10.
3.1.2 It is assumed that the equipment will define the
messages used in a particular implementation of SECS-
II. It is assumed the host will support equipment
implementation.
4 Referenced Standards
4.1 SEMI Standards
SEMI E4 — SEMI Equipment Communications
Standard 1 Message Transfer (SECS-I)
SEMI E6 — Guide for Semiconductor Equipment
Installation Documentation
4.2 ANSI Standard
1
ANSI X3.4-1977 — Code for Information Interchange
(ASCII)
4.3 IEEE Standard
2
IEEE 754 — Standard for Binary Floating Point
Arithmetic
4.4 The Japan Electronic Industry Development
Association (JEIDA) has requested that the SECS-II
standard incorporate support for the JIS-8 codes for
data exchange. This code would allow support for
1 American National Standards Institute, Headquarters: 1819 L
Street, NW, Washington, DC 20036, USA. Telephone: 202.293.8020;
Fax: 202.293.9287, New York Office: 11 West 42nd Street, New
York, NY 10036, USA. Telephone: 212.642.4900; Fax:
212.398.0023, Website: www.ansi.org.
2 Institute of Electrical and Electronics Engineers, IEEE Operations
Center, 445 Hoes Lane, P.O. Box 1331, Piscataway, New Jersey
08855-1331, USA. Telephone: 732.981.0060; Fax: 732.981.1721,
Website: www.ieee.org
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.