semi合集-English.pdf - 第7874页

SEMI T13-1104 © SEMI 2004 34 T r ace r Ta T r a cer Tb T r ac er T j T r a cer T k Cli ent Cx Mana ge r Mn / Tr a c e r T i M a na ge r M f / Tra c e r T c Ma c hine E 11 Machin e E 12 Mac h in e E 21 Ma c h i n e E 22 M…

100%1 / 7923
SEMI T13-1104 © SEMI 2004 33
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.
SEMI T13-1104 © SEMI 2004 34
Tracer
Ta
Tracer
Tb
Tracer
T
j
Tracer
T
k
Client
Cx
Manager
Mn
/ Tracer
T
i
Manager
M
f
/ Tracer
T
c
Machine
E
11
Machine
E
12
Machine
E
21
Machine
E
22
Machine
E
31
Machine
E
32
Machine
E
11 1
Machine
E
11 2
Machine
E
121
Machine
E
122
Machine
E
13 1
Machine
E
132
Die Trace
Data (DTD)
[takeDTD]
DTD
DTD
DTD
DTD
DTD
DTD
DTD
DTD
DTD
DTD
DTD
data data
no data
Ask Data (AD)
[
showDTD
]
A
D
A
D
A
D
A
D
A
D
Figure R3-1
An Example Transaction
SEMI T13-1104 © SEMI 2004 35
RELATED INFORMATION 4
USE CASE OF DEVICE TRACKING
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.
R4-1 Use Case Diagram
R4-1.1 Use Case diagram is one of well-known means for understanding and analysis of problem domain to start
with. It is often used before modeling a system or bringing a good solution.
R4-1.2 Use Case diagram consists of Actors and Use Cases. A use case defines something expected to a system
related to an actor or between actors. All use cases build up whole system.
R4-2 Use Case Diagram of Device Tracking
R4-2.1 The following diagram shows use case for Device Tracking.
R4-2.2 Trace — Consumer asks listing all or a part of stages of Production History and Information for tracking.
Examples may be picking up five latest history items or histories for changing substrates. Product Information may
include original production country, test house identification, assembly subcontractor and so on.
R4-2.3 Back Track — Consumer traces Production History from the latest one and checks also Problem Histories of
the state. If no specific essential problems is not found on the stage, information for previous stage is provided
interactively. If something is unclear, further information or data is requested to Producer.
R4-2.4 Update History — Producer append / updates Production History describing what has done on the product
including changing location or substrate. Information attached to the history may be dependent to the stage,
equipment and/or product. Producer may also append / update Problem History describing briefly what the problem
was and how it was fixed.
R4-2.5 Check History — Consumer asks detail history of a stage. System replies all or expected categories of
Production History and Information. Because sometimes Consumer's curiosity may beyond what system knows, the
system may ask further information to responsible producer in such case.
R4-2.6 Notify — Consumer notifies phenomena on a product to system when some problem happens on the
product. The system looks for resemble phenomena registered on the system. If it identified, the system let the
consumer know all information about the phenomena and update registry. Otherwise the system registers the
phenomena and asks all producers or most possible ones to fix it. When a responsible producer responds about the
problem, the system update registry and let the consumer know.
R4-2.7 Alert — Producer issues potential problems for a product. This information is registered on system and
distributed to all possible consumers. This capability can be used even if the product is still in process on some
stage.