semi合集-English.pdf - 第7734页

SEMI T12-0305 © SEMI 2004, 2005 13 I nvoice show Id show Attachm ents show T ypes show LoadPorts show Hi story Figure 12 Invoice Class 9.10.2 Invoice Class — Invoice Class defi nes its inhere nt data, behavi or and servi…

100%1 / 7923
SEMI T12-0305 © SEMI 2004, 2005 12
9.9.1 Inventory Object — The inventory is treated as Inventory object in most part of this specification. It may be
written sometimes as “Inventory” for short but it must be started with the capital letter ‘I’. Inventory object is an
instance of Inventory Class which is defined later. Tracking system has just one Inventory object.
Inventory
update
install
uninstall
showNamespace
changeNamespace
listUp
showData
Figure 11
Inventory Class
9.9.2 Inventory Class — Inventory Class defines its inherent data, behavior and services. This class manages all
Jigs and Implements in certain area. The area here may not be always special but may be logical in equipment type,
attachment type, supplier or nay combination of such category. This class is illustrated as above for reference.
9.9.2.1 Responsibility of Inventory — This class is responsible for managing and organizing registered Jigs and/or
Implements.
9.9.2.1.1 To complete the responsibility it accepts registration/unregistration of attachments, updating requests and
inquiry. They are defined as services of Inventory in this specification. Service names may be different from above
capabilities.
9.9.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.9.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.10 Invoice — Invoice is a set of information for such attachment as Jig or an Implement which is to be
transported to equipment. The information set is sent to the equipment before or after actual attachment has arrived.
If there is something wrong with the attachment or the information on the equipment, equipment ask for new one.
When another attachment or information has arrives, the equipment checks it again.
9.10.1 Invoice Object — Invoice object is created at the time a set of invoice information has received at
equipment. If the equipment has more than one load port for the attachment, port ID may be specified in the
information set. If port ID is not specified, destination port must be anonymous. If more than one attachment IDs or
Load Ports are specified, they are candidate but they are not ordering information nor correspondence between a
couple of sets. However there must be correspondent between attachments and histories. This object is removed at
the time all information has been verified regardless of the result. Invoice object is an instance of Invoice class
defined later. This object is abbreviated as “Invoice” in this document and often ‘object’ is omitted.
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.