semi合集-English.pdf - 第1635页

SEMI E38-1296 © SEMI 1995 , 1996 24 Table 2 Material Slot Attributes Attribute Name Definition Rqmt Access Form ObjType The object ty pe. Y RO Text: “MATER I ALSLOT” ObjID Module unique identifier f or the mater ial slot…

100%1 / 7923
SEMI E38-1296 © SEMI 1995, 199623
transfer activity and terminates the job. The intertool
port resource reports transfer job milestones achieved to
the cluster controller using the TRJobAlert service.
CM input/output transfer job object attributes required
to be accessible through object services:
Attribute Name Description: Requirements
ObjType The object type: transfer job.
TRJobID Identifier for the transfer job.
(Ordered list of)
TRAtomicID
Ordered list of identifiers for the
atomic transfers in the transfer job:
one atomic transfer for each material.
(List of)TRJobState All concurrent substates of the
transfer job.
Atomic transfer object attributes required to be
accessible through object services:
Attribute Name Description: Requirements
ObjType The object type: atomic transfer.
TRAtomicID Identifier for the atomic transfer.
TRLink Identifier to coordinate handoff: none.
TRPort CMPort through which transfer
occurs.
TRObjType Material Type: cassette or single
material.
TRObjName Material identifier.
TRRole Role in transfer control: secondary.
TRPartner Identifies partner if automated: none.
TRDirection Handoff direction: receive or send.
TRType Active/passive in transfer: passive.
(List
of)TRAtomicState
All concurrent substates of the atomic
transfer.
The requirements above indicate the settings if the
transfer is to be manual, with the operator. The
attributes TRLink, TRRole, TRPartner, and TRType are
not significant in this situation. These become
significant in automated material transfer.
Material movement messaging services required:
Message Name Description: Requirements
TRJobCreate Create transfer job: single material
send or receive, auto-start.
TRJobCommand Command on transfer job: abort.
TRJobAlert Notification: started, complete.
Intertool port resource capabilities required, but not
already specified above:
Detect and report success or failure of a transfer
job.
Reject incomplete, invalid, and unsupported
requests.
Intertool port resource capabilities permitted, but not to
be required, by a service-user:
Automated transfer of material within factory.
Stop, Pause, and Resume of a transfer job.
Manual atomic transfer start.
Transfer job queuing and queued job Cancel.
Transferring of material groups.
Multiple concurrent transfer jobs.
Notification of transfer events.
8.3.3 Carrier Mapping Services Mapping of
material in carriers across a cluster tool module
communications interface is achieved using the carrier
mapping services. These services provide the
communications required of the appropriate module
resources by the material models through defining the
material slot object.
The carrier-mapping services are fully specified in
terms of the material slot attributes accessed through
the get and set services of SEMI E39 (Object Services
Standard: Concepts, Behavior, and Services). Cluster
tool module communications require full compliance
with the information, behavior, and messaging services
of the fundamental requirements of that standard.
The mapping information is only of interest to the
cluster tool for a carrier contained in the module
resource. The material slot objects are, therefore,
associated with, and managed by, the module resource
which uniquely identifies all of its material slots. The
carrier-mapping services provide for communication of
material slot information in both directions between the
cluster controller and the module resource. The
information communicated is material presence and
material identification. Whether the material presence is
detected by the module resource or determined by the
cluster controller is application-specific. This is also the
case for material identification.
A material slot may be assigned the identifier of
material which is not yet occupying the material slot.
This provides for determination by the cluster controller
of which material slot the material is to be moved into
when it arrives at the module.
Material slot object attributes required to be accessible
through object services are detailed in Table 2.
SEMI E38-1296 © SEMI 1995, 1996 24
Table 2 Material Slot Attributes
Attribute Name Definition Rqmt Access Form
ObjType The object type. Y RO Text: “MATERIALSLOT”
ObjID Module unique identifier for the material slot. Y RO Text: Unique with respect to the module.
MtlName Identifier of the material occupying or
assigned to the slot.
YRWText
OccState Current state of the material slot. Y RW Text:
SlotUnknown
SlotEmpty
SlotOccupied
SlotActive
SlotDisabled
The material slot occupancy attribute indicates the presence of material as follows:
SlotUnknown — the carrier is present and slot occupancy is not known, such as from when a carrier is loaded
until the material is detected or the state is set by the cluster controller.
SlotEmpty — no material in the slot.
SlotOccupied — material is present in the slot.
SlotActive — material is being removed from, or is arriving at, the slot.
SlotDisabled — material slot unusable, such as when the carrier is not present.
Module resource capabilities required, but not already specified above:
Reject incomplete, invalid, and unsupported requests.
Module resource capabilities permitted, but not to be required, by the cluster controller:
Detection of the presence of material in a material slot.
Detection of the identifier of material in a material slot.
Table 3 lock Attributes
Attribute Name Definition Rqmt Access Form
ObjType The object type. Y RO Text: “CLOCK”
ObjID Module unique identifier for the clock. Y RO Text: Unique with respect to the module. Services
timestamp clock is “SERVICESCLOCK”
DateTime Current time. Y RW Text: yyyymmddhhmmsscc
8.4 Exception Management Services — Exception management across a cluster tool module communications
interface is achieved using the exception management services. These services provide the communications and
behavior required of the module resource by the exception models described in Section 7.1.5 through defining the
exception condition object and its operations.
The exception management services follow SEMI Draft Document 2013C (SECS II Support for SEMI E41
(Exception Management Standard)). Cluster tool module communications require full compliance with the
information, behavior, and messaging services of the fundamental requirements of that standard.
Exception conditions (alarms and error conditions) are created and managed by the module resource detecting the
related abnormal situation. The module resource uses the EXPost service to report the occurrence of the abnormal
situation or some significant change in exception condition information while the situation exists. EXCleared reports
that the abnormal situation is no longer apparent or relevant. Reporting on an exception condition is enabled and
disabled by setting its EXEnabled attribute.
SEMI E38-1296 © SEMI 1995, 199625
The cluster controller may direct recovery of error
conditions using the EXRecover service. The module
resource performs the recovery action and reports its
completion using the EXRecoveryComplete service.
The module resource is only required to permit a single
recovery action at a time on all set exception
conditions, but may support multiple recovery actions.
The module resource shall support the
EXRecoveryAbort service, which ceases any activity
and terminates the recovery action.
Exception condition object attributes required to be
accessible through object services:
Attribute Name Description: Requirements
ObjType The object type: EXCEPTION.
EXID Identifier for the exception condition.
EXType Type of exception condition:alarm or
error condition.
EXMessage Text message describing the
abnormal situation monitored.
EXEnabled Indicates reporting to decision
authority enabled/disabled.
EXRecActList Possible recovery actions (none for
alarms).
EXStateList All concurrent substates of the
exception.
Exception management messaging services required:
Message Name Description: Requirements
EXPost Notify/update on abnormal situation.
EXCleared Notify resolution of abnormal
situation.
EXRecover Command to perform recovery
action.
EXRecoveryComplete Notify completion of recovery action.
EXRecoveryAbort Command to abort a recovery action.
Reporting of all exception conditions is set to be
enabled on establishment of an association, and those in
the set state are posted.
Module resource capabilities required, but not already
specified above:
Reject incomplete, invalid, and unsupported
requests.
Module resource capabilities permitted, but not to be
required, by a service-user:
Multiple concurrent recovery actions.
Dynamic update of exception condition message
and valid recovery actions.
8.5 Recipe Management ServicesRecipe
management across a cluster tool module
communications interface is achieved using the recipe
management services. These services provide the
communications and behavior required of the module
by the recipe models described in Section 7.1.6 of this
document.
The recipe management services follow SEMI E42
(Recipe Management Standard). Cluster tool module
communications require full compliance with the
information, behavior, and messaging services of the
fundamental requirements of a recipe executor, and
optionally the recipe namespace management, as
defined in that standard.
The module requiring recipe services contains a recipe
executor that is capable of performing recipe download,
verification, selection, deselection, and deletion as
requested by the cluster controller. The module may
also support recipe namespace services.
In certain configurations, the module may require
recipe management services to be provided by the
cluster controller, in order that it may request a selected
recipe that is not stored locally. The module is the
service-user in this case, and the cluster controller
should support the necessary recipe namespace
services.
The module coordinates the activities of the processing
resource and the recipe executor to ensure the
appropriate recipes are loaded into the execution area
for material processing.
Recipe executor object attributes required to be
accessible through object services:
Attribute Name Description
ObjType The object type: “RcpExec”
ObjID Identifier for the recipe executor
DefaultNamespace Namespace for all hardware-dependent
recipes
RecipeSelectID List of recipe identifiers for the currently
selected recipe
Recipe management messaging services required:
Message Name Description: Requirements
RMEDnldVer Receive a recipe, optionally verify it, and
put it into storage
RMEDelete Delete a recipe from storage
RMESelect Select recipes for execution
RMEDeselect Deselect a recipe to prevent its execution
RMEComplete Notify service-user of completion of an
action