semi合集-English.pdf - 第1542页
SEMI E32-0997 © SEMI 1994 , 1997 37 are important issues that should be dealt with elsewhere. A1 -3 Error Handl ing — This se ction a ddresse s some common problems that may occur during t he transf er process. T his is …
SEMI E32-0997 © SEMI 1994, 1997 36
Table A1-1 Extended Atomic Transfer State Transition Table
# Current State Trigger New State Action Comment
1 (Undefined) Entry into PORT Model. INIT None. None.
2 INIT Port mechanisms found to be functional. NORMAL None. None.
3 NORMAL A malfunction of the hardware occurs. FAULT None. None.
4 FAULT The malfunction is “fixed.” This may be a manual re-
initialization of the port.
INIT None. None.
5 INIT A problem occurs during initialization. FAULT None. None.
6 (Undefined) Entry into PORT Model. NOT ALLOCATED None. None.
7 NOT
ALLOCATED
The port is allocated to transfer or process job. ALLOCATED None. None.
8 ALLOCATED Port is released from current job. NOT ALLOCATED None. None.
9 (Undefined) Entry into PORT Model. NOT PAUSED None. None.
10 NOT PAUSED Directive issued to pause port. PAUSING None. None.
11 PAUSING Port activity has ceased. PAUSED None. None.
12 PAUSED Directive issued to resume activity. NOT PAUSED None. None.
13 (Undefined) Entry into ALLOCATED state. IDLE None. None.
14 IDLE Task activity begins. BUSY None. None.
15 BUSY Task activity ends. IDLE None. None.
A1-1.2 Additional Related Mechanisms — Many
equipment material ports have additional related
mechanisms that can aid or interfere with a transfer.
These mechanisms can be represented as parallel (or
orthogonal) states within the port state model. Most
such state models will be simple two–state instances
(e.g., open/closed, on/off).
In some circumstances, the host will have a need to be
able to understand the status of these mechanisms and
may wish to be informed of state changes. This is
especially true if the host is to do error handling and
preliminary diagnosis of problems. The host also may
need some level of remote commands to manipulate
these mechanisms. Some possible transfer-related
mechanisms are discussed below.
Port Material Sensors: These sensors detect the
presence or absence of material in a port. The change in
this status is important, and an event should be provided
to report change in this condition.
Port Doors: Some equipment closes the environment
internal to the equipment, except during material
transfer. The applicable states are normally
open/closed.
Port Elevator: Port elevators have multiple states such
as HOME, MOVING, SLOT 5 ACCESS, or interlocks
such as BLOCKED BY INTERNAL TRANSFER
ARM.
Robot Arm: The transfer arm may be in motion, may
be holding material, etc.
Carrier Restraints: On some ports, carriers are clamped
in place and cannot be removed unless the restraints are
released. There would be a clamped/unclamped state
model.
A1-2 WIP Tracking — WIP tracking refers to the
ability of an entity (host or equipment) to keep accurate
track of the material within its domain. Typically, the
equipment is expected to track the material's location
within its modules and subsystems, while the host may
take a more global view, knowing at which equipment
(or storage area) a specific transfer object resides.
The process of material movement crosses the
boundary of the equipment domain. Therefore, there
must be information exchanged between host and
equipment about what material is being transferred and
what the plans are for the material (e.g., when and how
processed).
It is outside the scope of this standard to define WIP
tracking capabilities, either at the host or equipment
level. However, it is critical for the material movement
function to supply enough information that WIP
tracking is feasible. Specifically, the material
movement messaging must identify the object being
transferred. WIP references are kept at a minimum. For
example, for a carrier containing wafers, the material
movement process would need to know the carrier
identifier, but need not be concerned with the specific
lot contained within. It is also outside the scope of this
standard to be concerned with the detailed contents or
status (e.g., processed or not) of a transfer object. These
SEMI E32-0997 © SEMI 1994, 199737
are important issues that should be dealt with
elsewhere.
A1-3 Error Handling — This section addresses some
common problems that may occur during the transfer
process. This is not intended to present hard and fast
rules for error handling, but rather to raise potential
issues and suggest possible solutions. Several primary
error or interrupt types are covered. For state model
representations of hardware faults, see Section A1-1.
NOTE: Transfer errors are not completely communicated
between transfer partners. The host may be responsible for
pausing or aborting (as needed) the activities of the partner or
equipment with an error condition.
A1-3.1 Macro Level Error Handling
1. Transfer Specification Error
This would consist of an error in the data contained in
the Transfer Job Create request. Some examples might
include specification of a static port as an active
transfer partner or the use of a non–existent port on the
equipment. Such an error should result in rejection of
the Transfer Job Create request.
2. Setup Error
It is during the setup for an atomic transfer that many
prerequisites are typically checked. A setup error may
be either a hardware or a transfer specification problem.
Hardware problems might be such events as cassette
elevator fault, door fails to open, etc. If a hardware
problem occurs, the transfer job is paused and the
hardware state model makes a transition to the FAULT
state (see Section A1-1). When the problem is
corrected, the host may resume the activity or stop the
transfer job.
A transfer specification problem would typically relate
to the presence or absence of material at specified
locations. If there is a transfer specification problem
found, a transition to the RESTORE state is made
(transition #5) and the transfer job is terminated.
3. Restore Error
A restore error occurs when the port cannot be brought
back to its desired physical condition for the NOT
ALLOCATED state. This would be a failure of a
hardware mechanism. The hardware should then
transition to the hardware FAULT state (see Section
A1-1). The “completeness” of the transfer job may not
be hindered by problems in the restore activities.
However, the next transfer job may be affected.
4. Transfer Error
Transfer errors may be of many types and of varying
levels of severity. Any error that occurs must be
reported to the host. If the error is caused by failure of a
port mechanism, a transition to the hardware FAULT
state should occur (see Section A1-1). The problem
might also stem from a problem with the transfer
specification or in the transfer recipe (i.e., specification
is legal, but does not match that of the partner). If
failure in the transfer hardware has occurred, the
transfer job should transition to the PAUSED state and
report it to the host. The host may choose to abort the
transfer job, or correct the problem and resume the
transfer job.
5. Timeouts
To ensure that all transfer problems are detected, the
host should implement a process for timeout monitoring
of transfer jobs. The timeout periods need only be very
rough estimates of the actual times required for the
transfer job (e.g., 2× or 3× actual). The host might
choose to monitor individual atomic transfers if tighter
tolerances are required. The goal is to ensure that
problems are not left undetected over extended periods.
To determine the proper time to allow for a transfer job,
the host would sum the estimated maximum times
needed for the individual atomic transfers which make
up the job
14
. The atomic transfer time estimates would
typically be determined by experience, since they rely
on the interactions of two different transfer partners. A
doubling or tripling of the average observed transfer
time would be a good estimate. In some cases, suppliers
of dedicated transfer equipment may be able to supply
reasonable estimates.
Transfer job timeout monitoring should begin with the
receipt of the “Transfer Job Started” message and end
with the “Transfer Job Complete” message (both via the
TRJobAlert service). If the host is monitoring the
atomic transfers, monitoring should begin at the
“Atomic Transfer Started” event and end at the
“Atomic Transfer Complete” event (both via the
TRJobEvent service). The host must ensure that
reporting of these events is enabled in this case.
If a transfer job exceeds the timeout period, the host
may either pause the transfer job or attempt to end it
with the stop command. The former may be preferred,
since human intervention is required in either case and
may enable a resume command to continue the transfer.
A1-3.2 Micro Level Error Handling
1. No Communication With Transfer Partner
If a transfer partner attempts to communicate with its
transfer partner and finds that the communications link
is not responding, it should inform the host via an event
14 This assumes that atomic transfers proceed sequentially. If they
may proceed in parallel, the sequence for each port may be summed
and the longest total chosen as the estimated time.
SEMI E32-0997 © SEMI 1994, 1997 38
and continue to retry at intervals. Note that a disconnect
may be normal in some cases where the link is only
made when the transfer partners are in close proximity.
2. TRLink's Not Matched
If two transfer partners are attempting different
handoffs using the same physical resources (locations,
mechanisms, etc.), the host should be informed via an
event. The partners shall continue to await an
appropriate HOReady message—allowing the host to
“fix” one or the other of the partners. If an equipment
has no current transfer and it receives a HOReady
message, it should hold that message until a transfer job
is defined for it.
3. HOCommand Not Accepted
If the secondary transfer partner cannot accept a micro
command from the primary partner, it should use the
HOCommand Response message to inform the primary
partner that the command was rejected. The primary
partner may affect some recovery or inform the host
that the transfer has failed.
4. HOCommand Failed in Execution
If the secondary transfer partner fails in the execution
of an HOCommand, it should notify the primary partner
of the problem. The primary partner may affect some
recovery or inform the host that the transfer has failed.
5. Transfer Not Confirmed
If the secondary transfer partner sends a negative
HOVerify Response message saying that the transfer
object has not been properly transferred, the primary
partner should not attempt recovery, but inform the host
that the transfer has failed.
6. Timeout Awaiting Partner Readiness (HOReady)
Timeout Awaiting Micro Command Completion
(HOCommand Response)
Timeout Awaiting Transfer Verify Response
(HOVerify Response)
In some cases, action may be required if a transfer
partner has been awaiting communication from its
partner. The equipment should monitor timeout periods
for each of the three cases. The factory user may need
to customize the timeout periods for his/her factory.
When a timeout occurs, the equipment should notify the
host (via a TRJobEvent message) that the situation has
occurred, reset the timer, and continue to await the
partner. The host is responsible for taking any further
action which is required (e.g., Stop or Pause command).
A1-4 Practical Applications — This section provides
examples of practical applications of the material
movement services as presented in this document. Four
examples are provided below. Within these are
presented some major variations expected in a factory
situation. These are not exhaustive in scope, but the
expectation is that reviewing these examples will help
the reader understand how to apply these concepts to a
real application. These examples are also not intended
to represent a cohesive implementation strategy, but
rather some alternatives that might be considered.
AGVs are used in the examples below because they are
familiar to most readers, not because they are favored
over other transfer agents. To simplify the explanation,
the examples below deal only with movement of
cassettes.
A1-4.1 Passive Transfer — In this example, a transfer
is to be performed between an AGV with robot arm and
a piece of processing equipment. A cassette is to be
picked up by the AGV for later delivery to another
piece of equipment. The equipment has a cassette
indexer and a port door, but no other port-related
mechanism that would either aid or hinder transfer. The
chosen transfer mechanism provides for the equipment
to act as a passive transfer partner with no micro level
communications required. This is called a passive
transfer. The primary transfer partner is the AGV.
The setup for the equipment is to check to make sure
that the correct material is in the specified port, drive
the cassette elevator to the home position (if not already
there), and open the port door. Note that the first two
setup activities could have been designed to occur as a
part of the micro level transfer if desired. The setup
operations for the AGV are to ensure that its receiving
port is empty and to drive to the transfer position in
front of the designated equipment.
The transfer proceeds in the following steps:
1. The host sends a Transfer Job Create message to
each transfer partner.
2. The partners each accept the transfer job.
3. The equipment both have the needed available
resources so the transfer job immediately. Thus,
Transfer Job Started messages are sent to the host
by each.
4. Each partner in turn completes its setup activities
for the atomic transfer, sends a “Committed To
Transfer” event to the host, and then sends an
HOReady message to its transfer partner (via the
host).
5. Each partner sends the “Atomic Transfer Started”
event to the host as soon as it determines that it has
both sent and received an HOReady message for
this handoff.