semi合集-English.pdf - 第1060页

SEMI E5-1104 © SEMI 1982, 2004 2 1 Purpose 1.1 The SEMI E quipment Communicat ions Standard Part 2 (SECS-II) defines the details of the interpretation of messages exchanged b etween intelligent equipment and a host. This…

100%1 / 7923
SEMI E5-1104 © SEMI 1982, 2004 1
SEMI E5-1104
SEMI EQUIPMENT COMMUNICATIONS STANDARD 2 MESSAGE
CONTENT (SECS-II)
This standard was technically approved by the Global Information & Control Committee and is the direct
responsibility of the North American Information & Control Committee. Current changes approved by the
North American Regional Standards Committee on August 16, 2004. Initially available at www.semi.org
September 2004; to be published November 2004. Originally published in 1982; last published July 2004.
NOTICE: The user’s attention is called to the
possibility that some implementations of this standard,
particularly those related to the use of Stream 4, may
involve the use of inventions covered by U.S. patents
4,884,674 and 5,216,613, and by other patents issued or
pending, held by Texas Instruments Incorporated. By
publication of this standard, SEMI takes no position
respecting either the applicability or the validity of
these or other patent rights asserted in connection with
any item mentioned in this standard. Users of this
standard are expressly advised that determination of
any such patent rights, and the risk of infringement of
such rights, are entirely their own responsibility.
CONTENTS
1 Purpose
2 Scope
3 Limitations
4 Referenced Standards
5 Terminology
6 The Message Transfer Protocol
6.1 Intent
6.2 Messages
6.3 Blocking Requirements
6.4 Message Header
6.5 Transaction Timeout
6.6 Multiple Open Transaction
7 Streams and Functions
7.1 Streams
7.2 Functions
7.3 Stream and Function Allocation
8 Transaction and Conversation Protocols
8.1 Intent
8.2 Transaction Definition
8.3 Transaction Level Requirements
8.4 Conversation Protocols
9 Data Structures
9.1 Intent
9.2 Item
9.3 List
9.4 Localized Character String Items
9.5 Example Data Structures
9.6 Data Item Dictionary
9.7 Variable Item Dictionary
9.8 Object Dictionary
10 Message Detail
10.1 Intent
10.3 Message Usage
10.4 Stream 0 and Function 0
10.5 Stream 1 Equipment Status
10.6 Stream 2 Equipment Control and Diagnostics
10.7 Stream 3 Material Status
10.8 Stream 4 Material Control
10.9 Stream 5 Exception Handling
10.10 Stream 6 Data Collection
10.11 Stream 7 Process Program Management
10.12 Stream 8 Control Program Transfer
10.13 Stream 9 System Errors
10.14 Stream 10 Terminal Services
10.15 Stream 11 Host File Services (Deleted)
10.16 Stream 12 Wafer Mapping
10.17 Stream 13 Data Set Transfers
10.18 Stream 14 Object Services
10.19 Stream 15 Recipe Management
10.20 Stream 16 Processing Management
10.21 Stream 17 Equipment Control and Diagnostics
10.22 Stream 18 Subsystem Control and Data
11 Message Documentation
11.1 Intent
11.2 Standard Form SECS-II Document
12 Units of Measure
12.1 Intent
12.2 Units Symbol
12.3 Compliance
12.4 SECS-II Units of Measure Identifiers
Related Information 1
R1-1 The General Node Transaction Protocol
R1-2 Some Suggested Message Usage
R1-3 Notes on SECS-II Data Transfers
R1-4 Process Programs
R1-5 Suggested Baseline SECS Equipment
Implementation
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