semi合集-English.pdf - 第7840页
SEMI T12.2-0704 © SEMI 2004 69 C l i e n t (H T T P Cli en t ) B r o ke r (H T T P S e r v er ) H TTP P O S T < M e s s a g e C 1 > H TT P 2 0 0 < A c k n o w l e d g e > C l i e n t (H T T P Cl i ent ) B r o…
SEMI T12.2-0704 © SEMI 2004 68
RELATED INFORMATION 1
IPC MESSAGING MECHANISM and STRUCTURE
NOTICE: This related information is not an official part of SEMI T12.2 and was derived from the Japanese
Traceability Committee. This related information was approved for publication by full letter ballot on April 30,
2004.
R1-1 HTTP and SOAP Envelope
R1-1.1 The following diagram illustrates HTTP message border and SOAP Envelope structure. SOAP Header
contains information of the message and SOAP body just contains SOAP Faults to make sure what happens when
something wrong. Intended message service and its parameters are contained in second MIME Block to make it
possible to allow mixture of non-XML data.
R1-2 Communication with Message Broker
R1-2.1 The following diagrams show client-server communications with Message Broker.
HT TP 1.1
SOAP wit h MI ME Envelope
MI ME Block
MI ME Block
Mess age N ame and Par amet er s
SOAP Envelope
SOAP Body
SOAP Header
SOAP Fault s
Me s s ag e I n f o r ma t i on
Figure R1-1
SOAP Envelope and MIME Blocks
SEMI T12.2-0704 © SEMI 2004 69
Client
(H TT P Cli ent)
Br oker
(H TT P Se r ver )
HTTP POST <M essageC1>
HTT P 200 <A cknowledge>
Cl ient
(H T TP Cl i ent )
Broker
(H TT P Ser ve r )
H T T P POST <get M essag e>
HTT P 200 <MessageB1>
Cl ient
(HTTP Client)
Br ok er
(H TTP Ser ve r )
H TTP POST <g et Me ssage >
HTT P 200 <empt y>
H TTP POST <A ck nowledge>
HT TP 200 <empt y>
Cl ient
(H TT P Cli ent)
Br ok er
(H TT P Ser ve r )
H TTP POST <M essa geC2 >
H TTP 200 <A cknowledge>
Cl ient
(HTTP Client )
HTTP POST <get Message>
HTTP 200 <MessageC2>
HTTP POST <A cknowledge>
HT TP 200 <empt y>
Message f r om Client t o Br oker
Message f rom Broker t o Client
No Message f rom Broker to Client
Message between Clients
Figure R1-2
Communication with Message Broker
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 o
f
the contents in whole or in part is forbidden without express written
consent of SEMI.
SEMI T13-1104 © SEMI 2004 1
SEMI T13-1104
SPECIFICATION FOR DEVICE TRACKING: CONCEPTS, BEHAVIOR
AND SERVICES
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 April 30, 2004. Initially available at www.semi.org June 2004; to be published June
2004.
NOTICE: The designation of SEMI T13 was updated during the 1104 publishing cycle to reflect the creation of
SEMI T13.1 and SEMI T13.2.
1 Purpose
1.1 The purpose of this specification is to trace devices
for the sake of quality control, warranty, security or
any other reasons. This specification makes it easy to
transfer information required for realizing tracing in
such semiconductor products as dice and packaged
devices.
1.2 Because modern market trend of consumer minds,
industries and governments are explicitly or implicitly
requiring traceability for all products including
semiconductor devices. Implementing this specification
will help to satisfy both direct and indirect consumers
of semiconductor devices.
1.3 The other purpose of this document is to clarify
means to define coordinates to specify physical
position of devices on substrates which the other
standard documents don’t address. This information is
provided in Appendix sections.
2 Scope
2.1 This specification is intended to realize
semiconductor device tracking rather than production
itself. Even if some operations or communications for
tracing purpose may be related to factory automation or
production including measurement and maintenance,
they are not in the scope of this specification but
references to work within a factory.
2.2 Because the object of this specification is
traceability, tracing dice is not bounded on packaging
process of semiconductor devices. For example bare
dice may be mounted on Print Circuit Board (PCB).
This specification describes not only what is required
to trace dice in semiconductor manufacturing fab but
also what could be shared in PCB assembly lines or set
makers.
2.3 This document describes device tracking data
transfer between entities in a fab. Some entities may be
physical or logical depending on configuration of the
fab. Sometimes the transfer is carried out between
entities in different companies over such
communication media as internet or VPN (Virtual
Private Network). While this document describes the
transferring interface, it doesn’t define security
specification or criteria to be used with this
specification.
2.4 This document describes tracking semiconductor
devices. To make it possible to track final assembled
products of semiconductor devices consistently, this
document describes such assembled materials. Also,
sometimes a semiconductor device may consist of
more than one die. To track the smallest unit this
document often uses “Die Tracking” or “Die Tracing”
rather than “Device Tracking.”
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 While this specification could be effective in such
industry as PCB assembly, it is not required to comply
with this specification. Semiconductor device
producers who implement this specification will find
communicating die trace information with later
assembly manufacturers easier and more effective if
they comply this specification. The reverse is also true.
3.2 Because this specification doesn’t talk about
security considerations, implementers of this
specification are required realizing security data
transfer or connection with foreign computers. It is the
responsibility of the readers of this document to discuss
this issue between users and suppliers.
3.3 This document specifies logical information
definitions and related message exchanges required for
die trace systems, and assumes that any process or
equipment verifies passed material or product by any
means. This document doesn’t specify how it is done,
which ID tags and readers are recommended or where
and when it must be done. However target equipment
and production systems have to make sure the