semi合集-English.pdf - 第1535页
SEMI E32-0997 © SEMI 1994 , 1997 30 executed by th e primary partner. On l y one HOCommand may be active at any time. The list of commands to e xecute may b e included in a transfer recipe. See Section 4.2.4 ab ove for m…
SEMI E32-0997 © SEMI 1994, 199729
5 Micro Level
5.1 Micro Level Concepts — The micro level of
material movement is defined below to allow for
interaction between transfer partners on a step–by–step
basis during a handoff. It was designed to be used in
conjunction with the macro level defined above but
may instead be used with some other transfer
coordination mechanism.
5.1.1 Micro Level Definitions
Handoff — The process by which the transfer object
moves from the sending transfer partner to the receiving
transfer partner. The terms “handoff” and “micro level”
refer to the same transfer activity.
Micro Move — One of a sequence of moves required
during a micro level process to effect the transfer of an
object. This is normally associated with physical
activity within the transfer envelope.
5.1.2 Micro Level Description — While the macro
level of material movement deals with coordination and
preparation for a transfer, the micro level addresses the
physical synchronization between two transfer partners
during an atomic transfer. To control these physical
interactions properly, communication between the
transfer partners is required. Using these
communications, the partners shall ensure that both are
ready to perform the same specific transfer, that both
agree on the mechanism, and that movement within the
transfer envelope is properly coordinated.
There are three parts to the micro level interaction
between transfer partners. Each of the three parts must
occur in some form for the micro level to integrate
properly with the macro level.
1. The first part is the exchange of “I'm ready” type
messages, so that the partners can be sure that
starting the transfer is appropriate.
2. The second part of the micro level interaction is the
coordination of the physical transfer. During a
transfer, control of the transfer envelope may
belong to only one partner at any time. Joint or
parallel movement is never allowed in this space
13
.
The transfer itself is a series of steps called micro
moves. Each step typically contains all the
activities one partner can perform before the other
must act. If the secondary partner is passive during
the move, no micro level communications are
needed for part two, since the primary partner shall
control the transfer envelope during the entire
physical transfer.
13 The space outside the transfer envelope is not restricted, and some
preparations for the next micro move may be possible in this space.
3. The third part of the micro level interaction is the
verification that the transfer is complete.
The micro transfer mechanism assumes that the
secondary partner will recognize and respond to some
list of micro commands known to the primary partner.
These commands might range from the very specific
(e.g., “reach out and grasp the transfer object”) to the
very general (e.g., “perform the next step in your
sequence”).
5.2 Micro Level Behavior
5.2.1 Micro Level Communications — This section
provides baseline definitions of the communications
needed by the micro level of material movement. More
detailed definitions of the messaging services can be
found in Section 5.4 below. Refer to Figure 5.1 while
reading the message definitions. In the figure, the
messages in italics are macro level messages provided
for reference. The bolded messages are the micro level
messages.
The prefix “HO” (for HandOff) is appended to the
names of micro level messages to differentiate them
from the “TR” transfer messages.
HOReady — Upon completion of any setup operations,
each transfer partner shall declare to the other that it is
prepared for the specified atomic transfer. Either
partner may make this declaration first. When the
HOReady exchange has been made, the primary partner
shall start the transfer. The HOReady messages include
a transfer identifier (see TRLink), which the partners
match up. Looking back at the macro level atomic
transfer state diagram (Figure 4.6), the combination of
having sent and received a HOReady message for the
specific transfer will spur the transition from the
SETUP to AWAITING TRANSFER PARTNER states.
It is possible that an equipment will receive a HOReady
message from its partner before it has received the
corresponding Transfer Job Create request from the
host (e.g., setup is instantaneous). An equipment shall
be able to retain such a received message for a time to
allow the host to deliver the corresponding Transfer Job
Create request.
HOCommand — The HOCommand is the mechanism
by which the primary transfer partner orchestrates the
sequence of micro moves necessary for the transfer.
The primary transfer partner shall successively perform
its own micro move, then direct its partner to perform
its next move. Thus, the partners may alternate control
of the transfer envelope during the transfer. If the
secondary partner is passive during the entire transfer
and the primary performs all physical activity, no
HOCommands are required — they are implicitly
SEMI E32-0997 © SEMI 1994, 1997 30
executed by the primary partner. Only one
HOCommand may be active at any time.
The list of commands to execute may be included in a
transfer recipe. See Section 4.2.4 above for more detail.
Figure 5.1
Micro Level Message Flow
When the secondary partner is passive, no
HOCommands need be issued. In this case, all micro
moves are conceived of and executed by the primary
partner. The HOReady and HOVerify portions are still
required in this case.
HOCommand Complete — Once the secondary partner
has completed the task defined in the HOCommand, it
uses the HOCommand Complete response message to
alert the primary partner. If an HOCommand cannot be
accepted or fails, this message shall be used to convey
that information.
HOVerify — The primary transfer partner, believing all
micro moves complete, shall check its port to ensure
that the transfer object has been sent (or received) and
that all mechanisms are in a safe position. Next, it shall
send the HOVerify message to the secondary partner,
asking that it perform the same check.
HOVerify Response — The affirmative response from
the secondary partner confirms that the transfer was a
success. This message may alternatively signify
(through a data field) that the secondary partner does
not consider the transfer to be complete. This message
coincides with the transition for both partners from the
macro level TRANSFERRING state to the ATOMIC
TRANSFER COMPLETE state.
5.2.2 Micro Level Messaging via Host — As
mentioned above, all three parts of the micro level of
communications must be carried out in some form. If a
direct link from equipment to equipment exists, they
should occur via that means, whether using SECS–I,
Parallel I/O, or another protocol. If no direct link exists,
there is a means by which the host may relay micro
level messages from one transfer partner to the other.
This is illustrated in Figure 5.2.
Figure 5.2
Micro Level Message Flow via Host
In this situation, the host may act as a surrogate of each
equipment's transfer partner. A piece of equipment
would send the same defined micro level message as
before, but would deliver it to the host via the standard
host link. The equipment would treat the host as its
transfer partner, expecting the same response as if it
were talking directly to its true transfer partner. The
host is responsible for managing the relay of messages
from one partner to the other as necessary.
The equipment shall provide the ability to pass micro
level messages through the host. If a direct peer–to–
peer link is available, the user shall be able to configure
the path for the messages (directly to partner or through
the standard host link).
5.3 Extended Behavior — This section discusses two
micro level messages which may be exchanged
SEMI E32-0997 © SEMI 1994, 199731
between the transfer partners as a result of exceptional
conditions.
HOCancelReady — Once a transfer partner has sent a
HOReady message, it is committed to participate in a
transfer. Under some circumstances, an equipment
needs to withdraw from that commitment. The
HOCancelReady message is used for this purpose.
The HOCancelReady shall be accepted by the transfer
partner unless it has already sent the corresponding
HOReady. In cases where both transfer partners have
sent the HOReady message, the atomic transfer is
considered to have begun and cannot be canceled. If the
transfer partner receives an HOCancelReady, but has no
record of receiving the original HOReady, it should
accept the HOCancelReady.
HOHalt — The HOHalt message is used by a transfer
partner in situations when the equipment or transfer
object are endangered. The receiver of the HOHalt
message shall cease all movement related to the atomic
transfer immediately. Manual intervention is required
before the halted partner may resume movement.
5.4 Micro Level Services — This s ection expands
upon the messages defined in Section 5.2.1. It defines
the parameters of the messages and discusses the
possible values.
5.4.1 Service List — The following messages are
exchanged between transfer partners during an atomic
transfer.
Service Name Description Confirmed
HOReady Each partner sends this message
when it is ready to begin the
transfer process.
No
HOCommand Message sent by the primary
transfer partner to cause the
secondary partner to perform an
activity in the transfer envelope.
The response to this message
indicates completion of the
activity or error.
Yes
HOVerify Message sent by the primary
transfer partner informing the
secondary partner that all
activities should be complete
and asking for confirmation.
Yes
HOCancelReady Message sent to rescind a
previous HOReady message.
Yes
HOHalt Message sent to stop all action
by the transfer partner. This
message ends the transfer and
requires manual intervention at
the halted equipment.
Yes
5.4.2 Service Detail — The tables below define the
parameters for each service. In some cases, parameters
have additional detail which is defined in a following
section. These parameters are marked with the “*”
character.
The following codes are used in the definition of the
parameters (e.g., how each parameter is used in each
direction):
“M” — Mandatory Parameter—must be given a valid
value.
“C” — Conditional Parameter—may be defined in
some circumstances and undefined in others. Whether a
value is given may be completely optional or may
depend on the value of other parameter.
“U” — User-Defined Parameter.
“–” — Not Used.
“=” — (for Response only) Indicates that the value of
this parameter in the response must match that in the
primary (if defined).
The column labelled “Form” is used to indicate the type
of data contained in a parameter. The forms used in this
document are defined below.
Unsigned Integer — May take the value of any non–
negative integer. Messaging protocol may impose a
limit on the range of possible values.
Enumerated — The parameter may take on one of a
limited set of possible values. These values are
generally given textual names, but may have simpler
representations in protocol (e.g., numeric values).
Boolean — The parameter may take on one of two
possible values, equating to “True” and “False.”
Text — A text string.
Structure — A complex structure which consists of a
collection of values of one of the possible forms. The
breakdown of all “Structure” parameters is provided
within this document.