semi合集-English.pdf - 第7727页

SEMI T12-0305 © SEMI 2004, 2005 6 9.1.2.5 Fu rther Application Interfac e — Final purposes of tracking s u ch attac hments as Jigs and Implements are controlling life time of attac hments, increasing effectiven ess of at…

100%1 / 7923
SEMI T12-0305 © SEMI 2004, 2005 5
Inventory
HistoryDB
Attachment
HistoryRecord
Jig
Implement
PublicLocation
JitMachine
Secondment
Expiry
HistoryBuffer
1..*
0..*
Seconded
Jig
Seconded
Implement
manages
refers
has
occu
p
ies
verifies/creates
u
p
dates
invoices
1..*
cooperates
re
p
resents
represents logical partition in
Invoice
0..*
updates
Exception
creates /
sets u
p
buffers history
creates
/
u
p
dates
notifies
Figure 1
Modeling Jigs-Implements Tracking
9 Concepts
9.1 Domain Analysis and Object Based Modeling — To model and design complicated system or to have shared
specification of a part of system which is used widely in deferent applications, some sophisticated methodologies are
required. Analyzing problem domain by object oriented paradigm is one of the best practices to be taken. Because
this technology is frequently used in many SEMI standards, there is no confusion if this document follows the way.
9.1.1 UML Representation — Above diagram is modeling of Tracking Capability for Jigs and/or Implements in
UML diagram. It is not required to make system with object oriented programming language for compliant to this
specification. Even if UML is typical object oriented representation, object oriented implementation may be
expected but may not be mandatory.
9.1.2 Total Modeling — To make sure what the tracking system is, the model depicted above describes not just
tracking information acquisition but also includes fundamental management of the whole tracking system.
9.1.2.1 Acquisition of Minimum Tracking Information — Such capabilities as awareness of Attachments,
accumulation of use history until release timing and its report are required to acquire use-history of Jigs and/or
Implements on equipment. Cross-hatched classes (HistoryBuffer and Secondment) in light red and their
collaboration correspond to the acquisition capabilities. These capabilities are usually implemented on equipment.
9.1.2.2 Action on Expiration — One of the biggest purposes of tracking such Attachments as Jigs and/or
Implements is to prevent misprocessing with invalid attachments. An Attachment may be invalid when its use gets
beyond expected duration or cycles. This is such a capability as an expected action when an Attachment has been
expired by facing invalid situation. Light-red grided class (Expiry) and its collaboration correspond to the special
Action capabilities. This capability is usually implemented on equipment.
9.1.2.3 Identification and Verification of Attachments — Such information system as equipment controllers may not
understand what the attachment is even if attachment ID is known. Capability to understand that and verify between
information and physical attachment helps not only above fundamental capability but also ensured tracking. Pink-
hatched classes (JitMachine and Invoice) and their collaboration correspond to this capability. This capability is
also implemented on equipment usually.
9.1.2.4 Tracking Information Management — Such information system as Inventory is necessary to manage and
apply acquired Attachment tracking information effectively. Blue Thick-shadowed classes (Attachment,
HistoryRecord, Inventory and PublicLocation) and their collaboration correspond to this capability. This capability
is usually installed on master equipment, cell controller or host computer. Or it may be distributed on these
platforms.
SEMI T12-0305 © SEMI 2004, 2005 6
9.1.2.5 Further Application Interface — Final purposes of tracking such attachments as Jigs and Implements are
controlling life time of attachments, increasing effectiveness of attachments, preventing falt process and achieve
good quality of products. In this regard this interface capability helps applications. Green light shadowed class
(HistoryDB) corresponds this capability. This capability may be installed on the host or application server.
9.1.3 Collaboration in Class Modeling — An example of collaboration is as follows.
9.1.3.1 Application seeks certain type of jigs through HistoryDB. It finds good ones to produce expensive products.
It asks Inventory where they are.
9.1.3.2 It picks up the ones and delivers them to target equipments. It updates Inventory and Inventory sends
invoices to JitMachines. Invoice object is created on each JitMachine. At the time each jig arrives at each piece of
target equipment, the Invoice verifies. If verification succeeds, this fact is notified to Inventory, location is updated,
Secondment is created and JitMachine identifies what the sent jigs are. At the same time HistoryBuffer is also
created by the Secondment.
9.1.3.3 Equipment runs. HistoryBuffer accumulates events, process conditions and cycle. At some moment, it
reports the buffer content to Inventory. The Inventory manages HistoryRecord.
9.2 Attachment — Attachment represents a Jig or an Implement. This concept is used to handle common nature of
the both items.
9.2.1 Attachment object — Attachment object represents such supporting resource as Jig or Implement logically.
Attachment object is an instance of Attachment class defined later. Attachment object identifies corresponding
physical attachment and its information. This object is abbreviated as “Attachment” in this document and often
‘object’ is omitted.
Attachment
showId
showName
changeName
showType
showHistory
updateHistory
showLocation
updateLocation
Figure 2
Attachment Class
9.2.2 Attachment Class — Attachment Class defines its inherent data, behavior and services. This class generalizes
Jig and Implement registered in an Inventory. This class is illustrated as above for reference.
9.2.2.1 Responsibility of Attachment — This class is responsible for holding and organizing such information as
history for a Jig or Implement belonging to an Inventory.
9.2.2.1.1 To complete the responsibility it accepts creation/removal of a HistoryRecord, adding events or increment
time/duration requests and inquiry. They are defined as services of Attachment in this specification. Service names
may be different from capabilities above.
9.2.2.1.2 Inherent data is used to complete the responsibility. The data is also referred to as attributes and they have
to be defined in some way. This document doesn’t define attributes directly with attribute definition table shown in
some SEMI standard documents but defines them indirectly as service parameters.
9.2.2.1.3 Behavior is also defined to complete the responsibility. Behavior is often represented by collaboration
with outside of this class and state model. Collaboration reflects a part of associations of this class with others.
Collaboration works by asking services defined on accompanying object which is the other end of association on
class diagram. State model is representation of the other part of behavior of this class. However it has to be defined
if this class has explicit state, state model is not defined here because this class is stateless.
SEMI T12-0305 © SEMI 2004, 2005 7
9.3 Exception — Exception is unusual state on any Jig and/or Implement or on the tracking capability including
hazardous situation: potential or already destroy materials, attachments, equipment, explosive or insure/kill human.
Exception happens on equipment or may be storage capability of corresponding inventory. This fact may be added
to history.
9.3.1 Exception Object — Exception object represents unusual situation happened usually on equipment. It is
created at the time it is raised. It is destructed after normal condition is recovered from the situation. Exception
object is an instance of Exception class defined later. This object is abbreviated as “Exception” in this document
and often ‘object’ is omitted.
Exception
showId
showCategory
showCode
showDescription
showSubject
showState
updateState
destruct
Figure 3
Exception Class
9.3.2 Exception Class — Exception Class defines its inherent data, behavior and services. This class is illustrated
as above for reference.
9.3.2.1 Responsibility of Exception — This class is responsible for identifying situation, its status and such subject
as Jigs or Implements.
9.3.2.1.1 To complete the responsibility it accepts notification of state change or adding appendix for the state.
They are defined as services of Exception in this specification. Service names may be different from capabilities
above.
9.3.2.1.2 Inherent data is used to complete the responsibility. The data is also referred to as attributes and they have
to be defined in some way. This document doesn’t define attributes directly with attribute definition table shown in
some SEMI standard documents but defines them indirectly as service parameters.
9.3.2.1.3 Behavior is also defined to complete the responsibility. Behavior is often represented by collaboration
with outside of this class and state model. Collaboration reflects a part of associations of this class with others.
Collaboration works by asking services defined on accompanying object which is the other end of association on
class diagram. State model is representation of the other part of behavior of this class. Because this class has
explicit state, it defines following states and state model by state chart and transition definition table.
9.3.2.1.3.1 SET — Unusual situation is still effective.
9.3.2.1.3.2 CLEARED — Unusual situation is removed and it is normal condition about the cause of exception.
SET
CLEARED
EXCEPTION
1
2
3
Figure 4
Exception State