《SEMIE5-0709原版完整文件.docx》由会员分享，可在线阅读，更多相关《SEMIE5-0709原版完整文件.docx（295页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。
1、SEMI E5-0709SEMI EQUIPMENT COMMUNICATIONS STANDARD 2 MESSAGE CONTENT (SECS-II)This standard was technically approved by the global Information & Control Committee. This edition was approved for publication by the global Audits and Reviews Subcommittee on May 13, 2009. It was available at www.semi.or
2、g in June 2009 and on CD-ROM in July 2009. Originally published 1982; previously published November 2008.NOTICE: The users 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 b
3、y 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 men
4、tioned 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.Table of Contents1 Purpose32 Scope33 Limitations34 Referenced Standards and Documents35 Terminology46
5、The Message Transfer Protocol56.1 Intent56.2 Message56.3 Blocking Requirements56.4 Message Header56.5 Transaction Timeout56.6 Multiple Open Transactions67 Streams and Functions67.1 Streams67.2 Functions67.3 Stream and Function Allocation68 Transaction and Conversation Protocols78.1 Intent78.2 Transa
6、ction Definition78.3 Transaction Level Requirements78.4 Conversation Protocols79 Data Structures89.1 Intent89.2 Item89.3 List99.4 Localized Character String Items99.5 Example Data Structures109.6 Data Item Dictionary119.7 Variable Item Dictionary539.8 Object Dictionary6210 Message Detail7210.1 Inten
7、t7210.3 Message Usage7310.4 Stream 0 and Function 07310.5 Stream 1 Equipment Status7310.6 Stream 2 Equipment Control and Diagnostics80293SEMI E5-0709 SEMI 1982, 200910.7 Stream 3 Materials Status9910.8 Stream 4 Material Control11310.9 Stream 5 Exception Handling12710.10 Stream 6 Data Collection13210
8、.11 Stream 7 Process Program Management14210.12 Stream 8 Control Program Transfer15910.13 Stream 9 System Errors16010.14 Stream 10 Terminal Services16310.15 Stream 11 Host File Services (Deleted)16510.16 Stream 12 Wafer Mapping16610.17 Stream 13 Data Set Transfers17810.18 Stream 14 Object Services19
9、010.19 Stream 15 Recipe Management21010.20 Steam 16 Processing Management23810.21 Stream 17 Equipment Control and Diagnostics25410.22 Stream 18 Subsystem Control and Data26010.23 Stream 19 Recipe and Parameter Management26511 Message Documentation27511.1 Intent27511.2 Standard Form SECS-II Document2
10、7512 Units of Measure27612.1 Intent27612.2 Units Symbols27612.3 Compliance27712.4 SECS-II Units of Measure Identifiers278RELATED INFORMATION 1284R1-1 The General Node Transaction Protocol284R1-2 Some Suggested Message Usage284R1-3 Notes on SECS-II Data Transfers284R1-4 Process Programs287R1-5 Sugges
11、ted Baseline SECS Equipment Implementation2911 Purpose1.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 Electron
12、ic Industry Development Association Committee 12 on Equipment Communications.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 alternative message transfer protocols. The detai
13、ls of the message transfer protocol requirements are contained in 6.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 be construct
14、ed 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. Whil
15、e 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 Scope2.1 SECS-II gives form and meaning to messages exchanged between equipment and host using a message transf
16、er 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 c
17、orresponding 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
18、is governed by a set of rules for handling messages called the transaction protocol. The transaction protocol places some minimum 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 t
19、he users of this standard to establish appropriate safety and health practices and determine the applicability of regulatory or other limitations prior to use.3 Limitations3.1 SECS-II applies to equipment and hosts used in the manufacturing of semiconductor devices. Examples of the activities suppor
20、ted 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
21、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 in 10.
22、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 and Documents4.1 SEMI StandardsSEMI E4 SEMI Equipment Communications Standard 1 Message Transfer (SECS-I
23、) SEMI E6 Guide for Semiconductor Equipment Installation DocumentationSEMI E148 Specification for Time Sychronization and Definition of the TS-Clock Object4.2 ANSI Standard1ANSI X3.4-1977 Code for Information Interchange (ASCII)4.3 IEEE Standard2IEEE 754 Standard for Binary Floating Point Arithmetic
24、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 katakana characters in Japanese implementations of SECS-II.JIS-6226 JIS 8-bit Coded Character Set for
25、 Information Interchange, Japanese Industrial Standards.3NOTICE: Unless otherwise indicated, all documents cited shall be the latest published versions.5 Terminology5.1 Definitions5.1.1 The following brief definitions refer to sections providing further information.5.1.2 block a physical division of
26、 a message used by the message transfer protocol (see 6.3).5.1.3 conversation a sequence of related messages (see 8.4).5.1.4 conversation timeout an indication that a conversation has not completed properly (see 8.4.1).5.1.5 device ID a number between 0 and 32767 used in identifying the particular p
27、iece of equipment communicating with a host (see 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 7.2).5.1.8 host the intelligent system which communicates with the equipment.5.1.9 interpreter
28、the system that interprets a primary message and generates a reply when requested (see 6.2).5.1.10 item a data element within a message (see 9.2).5.1.11 item format a code used to identify the data type of an item (see 9.2).5.1.12 list a group of items (see 9.3).5.1.13 message a complete unit of com
29、munication (see 6.2).5.1.14 message header information about the message passed by the message transfer protocol (see 6.4).5.1.15 multi-block message a message sent in more than one block by the message transfer protocol (see 6.3.2).5.1.16 originator the creator of a primary message (see 6.2).5.1.17
30、 packet a physical division of a message used by the message transfer protocol (see 6.3).5.1.18 primary message an odd numbered message. Also, the first message of a transaction (see 6.2 and 7.2).5.1.19 reply the particular secondary message corresponding to a primary message (see 6.2 and 7.2).5.1.2
31、0 secondary message an even-numbered message. Also the second message of a transaction (see 6.2 and 7.2).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
32、 10036, USA. Telephone: 212.642.4900; Fax: 212.398.0023; http:/www.ansi.org2 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; http:/www.ieee.org3 Japanese Indu
33、strial 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; http:/www.jsa.or.jp5.1.21 single-block message a message sent in one block by the message transfer protocol (see 6.3.1).5.1
34、.22 stream a category of messages (see 7.1).5.1.23 transaction a primary message and its associated secondary message, if any (see 8.2).5.1.24 transaction timeout an indication from the message transfer protocol that a transaction has not completed properly (see 6.5).6 The Message Transfer Protocol6
35、.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 us
36、ing 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 transf
37、er 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 w
38、ith 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.6.3 Blocking Requirements The message transfer pr
39、otocol 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 sen
40、t 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 mess
41、age 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 mes
42、sages 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
43、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
44、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 I
45、D The message transfer protocol must be capable of identifying the device ID (032767) 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, mess
46、ages are identified by a stream code (0127, 7 bits) and a function code (0255, 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 me
47、ssage.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
48、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.6.6 Multiple Open Transactions This standard allows, but does not require, the support of more than one concurrent open transaction.7 Streams and Functions7.1 Streams A stream is a category of messages intended to