semi合集-English.pdf - 第7872页

SEMI T13-1104 © SEMI 2004 32 R2-3 Placing Message Name and Parameters in the Second MIME Block R2-3.1 Messaging with Attachment — If message may have bi nary value in i ts parameter, an attachment may be required. If tra…

SEMI T13-1104 © SEMI 2004 31

List 4 XML Messaging Envelope Example 1

<?xml version="1.0" encoding="UTF-8"?>

<SOAP-ENV:Envelope xmlns:SOAP-ENV=

"http://schemas.xmlsoap.org/soap/envelope/">

<SOAP-ENV:Header>

<MessageHeader xmlns="urn:semi-org:schema:xmlmsg:E128:0703"

elementFormDefault="qualified">

<From>MdmAbc001</From>

<To>DtHalNykA012</To>

<MessageType>REQUEST</MessageType>

<Action>takeDTD</Action>

</MessageHeader>

</SOAP-ENV:Header>

<SOAP-ENV:Body>

<data>

DeviceIdData xmlns="urn:semi-org:xsd.Doc3754.V0312.DeviceIdData">

SubstrateType>Strip</SubstrateType>

SubstrateId>MyStrip</SubstrateId>

LayoutId>Device</LayoutId>

OriginLocation>LowerLeftTop</OriginLocation>

RowColumnMajor>Column</RowColumnMajor>

D><Id></Id></D>

D><Id>Lot001-XXYY</Id></D>

D><Id>etc.</Id></D>

DeviceIdData>

</data>

</SOAP-ENV:Body>

</SOAP-ENV:Envelope>

NOTE 1: The above list is just an example and some details may not be fully compliant to SEMI E128 or related documents.

SEMI T13-1104 © SEMI 2004 32

R2-3 Placing Message Name and Parameters in the Second MIME Block

R2-3.1 Messaging with Attachment — If message may have binary value in its parameter, an attachment may be

required. If transferred data is binary format, some contrivance to encode the data is necessary unless the data is

transferred separately by another means: e.g. binary file transfer. This case XML Message has an attached block for

the data.

R2-3.1.1 IPC-2501 Style Data Report — The following list shows an example of XML messaging envelope with

attachment in accordance with IPC 2501 “Definition of Web-Based Exchange of XML Data (Message Broker)” for

the service ‘takeDTD’ of Die Tracer. SOAP Envelope in the first MIME Block has just message’s information in

element ‘MessageInfo’ of SOAP Header and SOAP Fault in SOAP Body if it is required. Message name and

message parameters are encapsulated in the second MIME Block.

List 5 XML Messaging Envelope Example 2

<?xml version="1.0" encoding="UTF-8"?>

<SOAP-ENV:Envelope xmlns:SOAP-

ENV="http://schemas.xmlsoap.org/soap/envelope/"

elementFormDefault="qualified">

<SOAP-ENV:Header>

<MessageInfo xmlns:IPC2501MI=

"http://webstds.gatech.edu/2501/MessageInfo.xsd"

elementFormDefault="qualified"

dateTime

= "2003-03-27T15:54:17.02-05:00"

sender= "MdmAbc001"

destination= "DtHalNykA012"

messageId= "123456"

messageSchema= "takeDTD">

</MessageInfo>

</SOAP-ENV:Header>

<SOAP-ENV:Body>

</SOAP-ENV:Body>

</SOAP-ENV:Envelope>

- - - Second MIME Block

<?xml version="1.0" encoding="UTF-8"?>

<takeDTD xmlns:TxxxDtTD=

"urn:semi-org:TC-Schema:Txxx:0704:DTO-TDS"

elementFormDefault="qualified"

dateTime

= "2003-03-27T15:54:17.02-05:00">

DeviceIdData xmlns="urn:semi-org:xsd.Doc3754.V0312.DeviceIdData">

SubstrateType>Strip</SubstrateType>

SubstrateId>MyStrip</SubstrateId>

LayoutId>Device</LayoutId>

OriginLocation>LowerLeftTop</OriginLocation>

RowColumnMajor>Column</RowColumnMajor>

D><Id></Id></D>

D><Id>Lot001-XXYY</Id></D>

D><Id>etc.</Id></D>

DeviceIdData>

</takeDTD>

NOTE 2: Above list is just an example and some details may not be fully compliant to IPC-2501 or related documents.

RELATED INFORMATION 3

AN EXAMPLE OF TRANSACTIONS HAPPENS IN DIE TRACING

SYSTEM

NOTICE: This related information is not an official part of SEMI T13 and was derived from the Japanese

Traceability Committee. This related information was approved for publication by full letter ballot on April 30,

2004.

R3-1 An Example of Transactions for Device Tracking

R3-1.1 The following sequence diagram shows typical transaction in Die/Device Tracking System. This diagram

illustrate an application how tracking runs and an example how this specification is applied.

R3-1.2 Characters in the Example — This example has a couple of die tracing system islands. Each of them is

supervised by independent Die Trace Manager: Mf and Mn. They may be separated areas in a frontend fab, frontend

and backend fabs, or semiconductor fab and SMT fab. Each island has three Die Tracers including the Manager.

Each Tracer has a couple of Die Trace Machines which can provide traceability functions and they must be doing

effective process for tracking. A Die Trace Client is located close to later process system: Cx.

R3-1.3 Script — The example shows transactions related to a certain products. Transactions flow through the

following stages.

R3-1.3.1 Usual Data Report — Each Machine report Die Trace Data for specific material for the product on

individual process.

R3-1.3.2 Initial Inquiry — The client needs to look for suspicious process to screen possible devices which may

have problem. It asks certain Die Trace Data to find the evidence of the problem to its one of familiar Tracers.

R3-1.3.3 Secondary Inquiry — The first Tracer Tk doesn’t have the data, so it asks its familiar Tracer or its

Manager. Unfortunately the Manager Mn/Ti doesn’t have that, so it asks to its subordinate Tracers: this case Tj only.

R3-1.3.4 Extended Inquiry — Because no subordinates have the data, there is nothing for the Manager but to

inquire the other Managers on tracking network. Inquired Manager Mf/Tc looks for to itself and asks its subordinate

Tracers.

R3-1.3.5 Replying Back — Fortunately one of the Tracers has the data and it responds to the Manager. The

Manager transfers to the other Manager as the response. The Client ended up with expected data.

R3-1.3.6 Flushed Inquiry — Above inquiries may be flushed at one time rather than step by step inquiry.