semi合集-English.pdf - 第7881页

SEMI T13.2-1104 © SEMI 2004 1 SEMI T13.2-1104 SPECIFICATION FOR XML PROTOC OL FOR DEVICE TRACKING This specificati on was technically approved by the Global Trac eability Committee and is the direct responsibility of the…

100%1 / 7923
SEMI T13.1-1104 © SEMI 2004 4
RELATED INFORMATION 1
SECS MAPPING FOR RESTRICTED INFORMATION
NOTICE: This related information is not an official part of SEMI T13.1 and was derived from the Japanese
Traceability Committee. This related information was approved for publication by full letter ballot on July 23,
2004.
R1-1 Particular Mapping for Specific Equipment
R1-1.1 Often some backend equipment may just handle such characteristic data of each device on a strip substrate
as sorting or classification data and transfer information. Characteristic information exchanging service messages
and their parameters are mapped as shown in the following tables. This mapping is one of possible specific
mappings for arrayed characteristic device information on a strip and there may not be a full mapping but just for
particular functions related to the exchanging services. This mapping is based on SEMI G84 with some extension.
Table R1-1 Service Instructions Mapping
Service Message Name Supporting Class Stream, Function SECS-II Message Name
showData DieTraceData S14, F1/F2 Get Attribute Request / Data.
ShowProperty DieTraceData S14, F1/F2 Get Attribute Request / Data.
takeDTD DieTracer S6, F11/F12 Selected Equipment Status Request / Data.
Table R1-2 Service Parameters Mapping
Parameter Name SECS-II Data Item Reference SECS-II Format Remarks
DataValue L, 2
1. <ATTRID>
2. <ATTRDATA>
ATTRID = (20)
ATTRDATA = (0, 1x, 2x,
3x, 4x, 5x)
showData of DieTraceData
(specific use for data content, or
whole characteristic map data on
a substrate including some
properties).
Designation <ATTRID> ATTRID = (20) showProperty of DieTraceData.
Property L, 2
1. <ATTRID>
2. <ATTRDATA>
ATTRID = (20)
ATTRDATA = (0, 1x, 2x,
3x, 4x, 5x)
showProperty of DieTraceData.
<ACKC6> ACKC6=(10) showData, showProperty. ServiceStatus
<OBJACK> OBJACK=(51) takeDTD of DieTracer.
TraceData <V> V=(0, 1x, 2x, 3x, 4x, 5x) takeDTD of DieTracer.
NOTICE: SEMI makes no warranties or representations as to the suitability of the standards set forth herein for any
particular application. The determination of the suitability of the standard is solely the responsibility of the user.
Users are cautioned to refer to manufacturer's instructions, product labels, product data sheets, and other relevant
literature, respecting any materials or equipment mentioned herein. These standards are subject to change without
notice.
By publication of this standard, Semiconductor Equipment and Materials International (SEMI) takes no position
respecting the validity of any patent rights or copyrights asserted in connection with any items mentioned in this
standard. Users of this standard are expressly advised that determination of any such patent rights or copyrights, and
the risk of infringement of such rights are entirely their own responsibility.
Copyright by SEMI® (Semiconductor Equipment and Materials
International), 3081 Zanker Road, San Jose, CA 95134. Reproduction of
the contents in whole or in part is forbidden without express written
consent of SEMI.
SEMI T13.2-1104 © SEMI 2004 1
SEMI T13.2-1104
SPECIFICATION FOR XML PROTOCOL FOR DEVICE TRACKING
This specification was technically approved by the Global Traceability Committee and is the direct
responsibility of the Japanese Traceability Committee. Current edition approved by the Japanese Regional
Standards Committee on July 23, 2004. Initially available at www.semi.org September 2004; to be published
November 2004.
1 Purpose
1.1 The purpose of this document is to map Services
and data in SEMI T13 into XML protocol.
2 Scope
2.1 This document is applied to XML implementation
of Jigs and Implements traceability with some
interoperability with Surface Mount Technology (SMT)
equipment.
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 This protocol mapping has a consideration being
interoperable with SMT manufacturing it may be used
in such area, using this specification on such
manufacturing area is not guaranteed because this
specification is originally planned to be working on
semiconductor manufacturing systems including
equipment.
4 Referenced Standards
4.1 SEMI Standards
SEMI T12 — Specification for Tracing Jigs and
Implements
SEMI T13 — Specification of Device Tracking:
Concepts, Behavior and Services
4.2 Association Connecting Electronics Industries
(IPC)/National Electronics Manufacturing Initiative
(NEMI)/American National Standard institute (ANSI)
1
IPC-2501 — Definition for Web-Based Exchange of
XML data; (July, 2003)
IPC-2541 — Generic Requirements for Electronics
Manufacturing Shop-Floor Equipment Communication
1 http://www.ipc.org, http://www.nemi.org, http://www.ansi.org, The
original developer is IPC with NEMI cooperation, ANSI ends up with
authorizing approval.
(CAMX); (October, 2001 / ANSI Approved November,
2001)
4.3 World Wide Web Consortium (W3C)
2
REC-xml-20001006 — Extensible Markup Language
(XML) 1.0 (Second Edition)
NOTE-SOAP-20000508 — Simple Object Access
Protocol (SOAP) 1.1
4.4 Internet Engineering Task Force
3
RFC2045 — Multipurpose Internet Message
Extensions (MIME) Part 1: Format of Internet Message
Bodies
RFC2616 — Hyper Text Transfer Protocol – HTTP/1.1
NOTICE: Unless otherwise indicated, all documents
cited shall be the latest published versions.
5 Terminology
5.1 Abbreviations & Acronyms
5.1.1 MIME — Multipurpose Internet Message
Extensions
5.1.2 SOAP — Simple Object Access Protocol
5.1.3 XML — eXtensible Markup Language
6 Base Requirements
6.1 Base Protocol Mapping — This XML protocol
specification adopts Simple Object Access Protocol
(SOAP) over Hyper Text Transfer Protocol (HTTP) on
Transmission Control Protocol/Internet Protocol
(TCP/IP). Some equipment users produce not only
semiconductor devices but also Print Circuit Boards
(PCBs). It is convenient for such users to have common
messaging protocol with standard messaging for
Surface Mount Technology (SMT). For this purpose
this protocol mapping extension standard specifies the
messaging mechanism conformant to IPC-2501
“Definition for Web-Based Exchange of XML Data” as
2 World Wide Web Consortium, 32 Vassar St. Room 32-G515,
Cambridg, MA 02139, USA Telephone: 617.253.2613; Fax:
617.258.5999, http://www.w3c.org,
3 http://www.ietf.org, IETF Secretariat c/o
Corporation for National
Research Initiatives, 1895 Preston White Drive, Suite 100, Reston,
VA 20191-5434, USA, Telephone +1 703 620 8990, Fax +1 703 620
9071
SEMI T13.2-1104 © SEMI 2004 2
one of mapping means. Also this extension standard
document follows IPC-2541 “Generic Requirements for
Electronics Manufacturing Shop-Floor Equipment
Communication Messages” and IPC-2551 “Sectional
Requirements for Manufacturing Execution System”
for that reason. The following subsections describe a
part of these specifications for introduction. Refer to
these documents for detail reference.
6.2 SOAP Structure — A HTTP message in this
specification has an envelope to contain a couple of
MIME blocks. One is for SOAP Envelope and the other
is for message detail to be able to mix with such non-
XML information as binary data. The service message
specified in SEMI T12 is contained in latter one. SOAP
standard envelope MIME Block contains SOAP Header
which has message information and SOAP Body which
contains SOAP Faults. Outlined diagram is shown in
Related Information. Official definitions are given in
referenced documents.
6.3 Messaging Mechanism — Message Broker, that is
logical middle ware server to handle and relay
messages, is assumed somewhere on communication
network. While the broker behaves as communication
server, the other logical nodes are message clients.
Every message starts with a client and responded by the
server. Messages communicated between clients are
exchanged through the server. The server keeps posted
messages from clients in a queue for each individual
client. Expecting recipient client asks the server for
messages and a topmost message in the queue for the
client is responded if the queue is not empty. The
recipient client posts acknowledge back to the server.
When the recipient replies back a message to the
original sender client, same thing happens with
switched roles between sender and recipient clients.
Explanatory diagrams for this outline are shown in
Related Information. Official specification is given in
referenced documents.
6.4 Issues Specific to this Messaging — A few issues
for IPC based communication protocol for Jigs and
Implements Tracking are introduced here.
6.4.1 Domain Configuration — Message Broker has
domain configuration information to make sure all
acting entities, possible messages with related
publisher, recipient and subscriber clients. Also it has
other detail characteristics of the domain of
communication. Every client needs to look up the
information before the first messaging.
6.4.2 Message Information — This is an element
contained in SOAP Header. This information provides
time of transaction, sender, destination, message
identification and schema type used for service message
detail in the second MIME block.
6.4.3 Attributes in Service Message Element — The
top element of each service message has date/time of
the message, session ID or session reference, request ID
or request reference, and optional values. Some of the
optional values are extended for Jigs and Implements
Tracking communication: linkId, linkCnt and linkExp.
The extension may be used for delayed reply message
and multiple divided replies to keep conformance of
related messages.
7 Requirements
7.1 Service Mapping — Services defined in SEMI T12
are mapped on the following table.
7.1.1 Capitalized Service Message Element Name Base
— Each service message is mapped into an XML
element with capitalized heading letter to prevent
collision with XML or XML Schema native words.
7.1.2 Service Message Element Name Suffix —
Because of symmetry of message broker
communication and for XML element naming
convention, suffix of ‘Request’ or ‘Response’ is added
to each service message element name for request or
response respectively: e.g. AddEventRequest to request
service and AddEventResponse for its response
message.
Table 1 Service Instruction Mapping
Service Message Name Supporting Class Service Message Element
Name Base
Remarks
acquireDTD DieTraceMachine AcquireDTD
admit DieTraceManager Admit
catchDTD DieTracer CatchDTD
collectDTD DieTracer CollectDTD
devolve DieTraceManager Devolve
enroll DieTracer Enroll
flush DieTraceMachine Flush