semi合集-English.pdf - 第7735页

SEMI T12-0305 © SEMI 2004, 2005 14 9.11.2.1 Responsibility of JitMachine — This class is resp onsible for verifying attachments, re porting in/out of equipment and organizi ng Jigs or Im plements. 9.11.2.1.1 To complete …

100%1 / 7923
SEMI T12-0305 © SEMI 2004, 2005 13
Invoice
showId
showAttachments
showTypes
showLoadPorts
showHistory
Figure 12
Invoice Class
9.10.2 Invoice Class — Invoice Class defines its inherent data, behavior and services. This class provides
information about Jig or Implement to be tracked on equipment. This class is illustrated as above for reference.
9.10.2.1 Responsibility of Invoice — This class is responsible for holding and organizing invoice information as
well as verification. This object verifies physical attachments with invoice information at the time this object has
been created with unverified attachments on equipment or new physical attachment arrives.
9.10.2.1.1 To complete the responsibility it accepts inquiries of inherent information. They are defined as services
of Invoice in this specification. Service names may be different from above capabilities.
9.10.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.10.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.
9.11 JitMachine — JitMachine is a piece of equipment with full tracking capability of Jigs and/or Implements.
JitMachie collaborate with Inventory so that the inventory fulfills its responsibility.
9.11.1 JitMachine Object — JitMachine object represents a piece of equipment which completes responsibility for
tracking such attachments as Jigs and/or Implements on equipment. It verifies passed attachments whether they are
right ones to be used on the equipment or not even if they are expected type or compatible. It also let the inventory
know that certain attachments have arrived at the equipment or left for the inventory. JitMachine object is an
instance of JitMachine class defined later. This object is abbreviated as “JitMachi” in this document and often
‘object’ is omitted.
JitMachine
showId
showName
showType
recieveInvoice
showAttachments
showExceptions
Figure 13
JitMachine Class
9.11.2 JitMachine Class — JitMachine Class defines its inherent data, behavior and services. This class is
illustrated as above for reference.
SEMI T12-0305 © SEMI 2004, 2005 14
9.11.2.1 Responsibility of JitMachine — This class is responsible for verifying attachments, reporting in/out of
equipment and organizing Jigs or Implements.
9.11.2.1.1 To complete the responsibility it accepts invoice which shows what are delivered attachments and related
requests. They are defined as services of JitMachine in this specification. Service names may be different from
capabilities above.
9.11.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.11.2.1.2.1 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.11.2.1.2.2 INSERVICE — JitMachine is available to track Attachments.
9.11.2.1.2.3 OUTOFSERVICE — JitMachine is not available to track Attachments.
JITMACHINE
C
1
2
3
OUTOFSERVICE
INSERVICE
Figure 14
JitMachine State
Table 4 Transition Definition Table for JitMachine
# Previous State Trigger New State Actions Comments
1 (No state) JitMachine has been initialized. INSERVICE [or]
OUTOFSERVICE
2 INSERVICE Problem happens on equipment to
prevent from tracking including users
operation to suspend.
OUTOFSERVICE Service except inquiry
may not be accepted.
3 OUTOFSERVICE Problem to prevent equipment from
tracking is removed including users
operation to resume.
INSERVICE
9.12 Public Location — Public Location represents a location of a Jig or an Implement on the tracking system.
This is just for official location other than such private location as detail position in equipment. A public Location
may have more than one Jigs and/or Implements.
9.12.1 Public Location Object — Public Location object represents an official location potentially occupied by such
supporting resource as a Jig or an Implement and identifies what occupant is if it is occupied. Public Location
object is an instance of Public Location class defined later. This object doesn’t identify physical location in
equipment. This object is abbreviated as “PublicLocation” in this document and often ‘object’ is omitted.
SEMI T12-0305 © SEMI 2004, 2005 15
9.12.1.1 Public Location object is assigned on a piece of equipment and represent one and only one official location
of the equipment. However a piece of equipment may have more than one Public Location objects, they have to be
prepared for different types of Attachments. But a Public Location may be used by two or more different
attachment types if they can share the physical attachment location and such side effects as contamination may not
be expected.
9.12.1.2 It may be also assigned in physical or logical inventory. More than one Public Location may be defined
for the inventory. If it is physically divided, each location have to be prepared for physically categorized
attachments such view point as attachment types or allowable dimensions. If it is logically divided, there have to be
explicit rule to distribute or the inventory has to manage implicitly.
PublicLocation
showId
showName
changeName
showLocationType
showPossibleTypes
showCapacity
showAvailableSpace
showAttachments
updateOccupancy
showState
updateState
Figure 15
PublicLocation Class
9.12.2 Public Location Class — Public Location Class defines its inherent data, behavior and services. This class is
illustrated as above for reference.
9.12.2.1 Responsibility of PublicLocation — This class is responsible for identifying location, its status including
remaining room to be occupied by Jigs or Implements and manage them.
9.12.2.1.1 To complete the responsibility it accepts many inquiries about inherent data of the class or request to
update them. They are defined as services of PublicLocation in this specification. Service names may be different
from capabilities above.
9.12.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.12.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.12.2.1.3.1 UNOCCUPIED — Public Location is not occupied by any jig or implement.
9.12.2.1.3.2 OCCUPIED — Public Location is occupied by some jigs or/and implements.
9.12.2.1.3.3 VACANT — Public Location is occupied by some jigs or implements and further occupancy is
possible.
9.12.2.1.3.4 FULL — Public Location is occupied by some jigs or implements and no further occupancy is allowed.