semi合集-English.pdf - 第1634页

SEMI E38-1296 © SEMI 1995 , 1996 23 transfer activity and term inates the j ob. The intertool port resource reports transfer job milestones achie ved to the cluster controller using the TRJobAlert service. CM input/outpu…

SEMI E38-1296 © SEMI 1995, 1996 22

3. a verification phase to determine that actual

handoff took place. This action completes the

handoff.

The transport module is responsible for managing

constraints on the simultaneous opening of isolation

valves as it relates to contamination of the transport

module's environment by that of an attached module, as

well as cross-contamination between modules. The

attached module ensures that its environment will not

contaminate the transport module before synchronizing.

The rules for re-establishing isolation at verification are

determined by the transport module.

The synchronization between the transfer resource and

the intratool port resource is achieved by each,

indicating readiness to transfer the material, using the

HOReady service. Once both partners have received the

HOReady, the intratool port resource directs the

physical handoff. The intratool port resource commands

the transfer resource using the defined HOCommand

services. Once the physical handoff is complete, the

intratool port resource requests verification using the

HOVerify service.

The transfer resource and intratool port resource shall

support the HOCancelReady service which cancels a

previously sent HOReady while still in the

synchronization phase. The transfer resource shall

support the HOHalt service, which ceases any transfer

activity and terminates the handoff.

Material movement messaging services required:

Message Name Description: Requirements

HOReady Synchronize with partner.

HOCommand Command to the transport resource to

perform an activity in the transfer

envelope. Detailed below.

HOVerify Verification of handoff completion

with transfer resource.

HOCancelReady Rescinds previous HOReady

message.

HOHalt Command to the partner to stop all

action.

HOCommands to be supported by the transfer resource:

Command Description: Requirements

Pick Commands the transfer resource to

take all actions necessary to remove

the material from the intratool port.

Place Commands the transfer resource to

take all actions necessary to place the

material in the intratool port.

Command Description: Requirements

Extend Commands the transfer resource to

reach into the intratool port to a

predefined position at which the

material can be accepted or released.

Retract Commands the transfer resource to

withdraw from the intratool port.

Where the robotic hardware does not provide for

vertical motion, Pick and Place are not required to be

supported.

Transfer partner capabilities required, but not already

specified above:

• Detect and report success or failure of handoff

commands.

• Detect and report success or failure of the handoff,

through the verification.

• Reject incomplete, invalid, and unsupported

requests.

Transfer resource capabilities permitted, but not to be

required, by either partner:

• Multiple concurrent handoffs.

• Additional handoff commands.

8.3.2 Intertool Material Movement Services —

Factory-to-cluster tool carrier or single material

input/output management across a cluster tool module

communications interface is achieved using the

intertool material movement services. These services

provide the communications and behavior required of

the intertool port resource by the intertool material

movement models through defining the CM

input/output transfer job object and its operations.

This standard specifies only the required

communication between the cluster controller and the

cassette module and does not assume automated

material movement in the factory. The CM input/output

transfer job is compliant with SEMI E32 (Material

Movement Management) and may be extended to

support automated material movement in the factory.

The CM input/output transfer job creation is requested

by the cluster controller using the TRJobCreate service.

If the intertool port resource accepts the job, it

coordinates with the operator or some entity to achieve

the material handoff. The CM input/output transfer job

comprises an atomic transfer for a cassette or single

material which is to receive it from, or send it to, the

factory.

The intertool port resource shall support the

TRJobCommand Abort service, which ceases any

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.

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.