semi合集-English.pdf - 第1527页

SEMI E32-0997 © SEMI 1994 , 1997 22 Table 4.4 E xtended A tomic Transfer State Trans ition Table # Curre nt State Trigger New State Action(s) Comment 3 SE TUP P reparatio n for atomic transfer is comple te, and T RAutoSt…

100%1 / 7923
SEMI E32-0997 © SEMI 1994, 199721
4.3.3 Extended Atomic Transfer State Model — Figure
4.8 presents an extended atomic transfer state model.
This model extends the atomic transfer model in a way
similar to the transfer job extension. It provides for the
capability to pause/resume and to abort
12
. Except for
the extensions, this model is the same as that presented
as Figure 4.6. Therefore, only the extensions are
discussed in this section.
Figure 4.8
Extended Atomic Transfer State Diagram
WAIT
The atomic transfer stops activity and awaits a
StartHandoff command from the host. This capability
allows the host to precisely orchestrate the timing of the
handoff in time critical operations.
ABORT
The ABORT state is an AND substate of TRANSFER
ACTIVE. This state is responsible for coordination of
any activities necessary to abort the active atomic
transfer. The ABORT state has two substates:
ABORTING and NOT ABORTING.
NOT ABORTING
In this state, the abort process is not in effect. The
atomic transfer proceeds normally.
12 Note that “stop” does not apply to atomic transfers, since the
active atomic transfers are allowed to complete when the transfer job
is stopped.
ABORTING
In this state, the process of aborting is performed. It is
the responsibility of the equipment to cease physical
activity as quickly as possible and end the current
atomic transfer. This process is application-specific. It
is the responsibility of the supplier to document this
method.
PAUSE
The PAUSE state is an AND substate of ATOMIC
TRANSFER ACTIVE. That is, the pause states are
concurrent with the execution states of the atomic
transfer. The PAUSE state has three substates: NOT
PAUSED, PAUSING, and PAUSED.
NOT PAUSED
A newly activated atomic transfer is NOT PAUSED by
default. In this state, the atomic transfer proceeds as
normal.
PAUSING
This state is coordinating the movement of the atomic
transfer from NOT PAUSED to PAUSED. It is
responsible for making sure that the current activity for
the atomic transfer has ceased at an appropriate point.
PAUSED
All activity has ceased. The atomic transfer is awaiting
a Resume command. Note that the PORT A, PORT B,
etc., substates retain their current states, but their
activity ceases when PAUSED.
The following transition table defines the added
transitions between states for the extended atomic
transfer state model. It applies to Figure 4.8.
SEMI E32-0997 © SEMI 1994, 1997 22
Table 4.4 Extended Atomic Transfer State Transition Table
# Current State Trigger New State Action(s) Comment
3 SETUP Preparation for atomic transfer
is complete, and TRAutoStart
parameter is TRUE.
AWAITING XFR
PARTNER
None. “Committed to Transfer”
event
7 ABORTING Abort process is complete. ATOMIC
TRANSFER
COMPLETE
None. “Atomic Transfer
Complete” event occurs
noting abnormal
termination.
8 (Undefined) Default entry into PAUSE. NOT PAUSED None. None.
9 NOT PAUSED The transfer job transitioned to
PAUSING state (Transition 12,
Figure 4.7).
PAUSING None. None.
10 PAUSING All atomic transfer activity has
ceased.
PAUSED None. None.
11 PAUSED The host issued a directive to
resume the atomic transfer.
NOT PAUSED None. None.
12 (Undefined) Default entry into ABORT. NOT ABORTING None. None.
13 NOT ABORTING Transfer job transitioned to
ABORTING state (Transition
18, Figure 4.7).
ABORTING Begin abort
activities.
May be host- or
equipment- initiated.
14 ATOMIC
TRANSFER
QUEUED
Abnormal Transfer Job
termination.
ATOMIC
TRANSFER
COMPLETE
None. May be caused by transfer
job abort or stop.
15 SETUP Preparation for atomic transfer
is complete, and TRAutoStart
parameter is FALSE.
WAIT Wait for host
command.
None.
16 WAIT StartHandoff command is
received from host.
AWAITING XFR
PARTNER
None. “Committed to Transfer
2” event
4.4 Macro Level Services — This section defines the messaging services required to implement the material
movement concepts. The messages were introduced in Sections 4.2.1 and 4.3.1. These services are independent of
the messaging protocol to be used. They may be mapped to SECS–II (SEMI E5) or to other comparable protocols.
These messaging services define the messages to be used, the nature of the data items or parameters to be contained
within the messages, and data type of the parameters. Not defined here is the internal structure of the actual
messages as transferred, including order of the parameters and how various data structures and data types are
represented.
4.4.1 Service List — The following messages are exchanged between host and equipment for the purpose of
accomplishing material movement tasks.
Host Initiated Services
Service Name Description Confirmed*
TRJobCreate Host request that a transfer job be performed. Yes
TRJobCommand Command which affects a transfer job. Yes
GetAttribute Request for attributes of an object (e.g., transfer job or atomic
transfer). This message service has applicability beyond material
movement.
Yes
* An unconfirmed service requires no response to the request message. This means that no data is required in the response. This does not preclude
the implementation of a response message in the message protocol.
SEMI E32-0997 © SEMI 1994, 199723
Equipment Initiated Services
Service Name Description Confirmed
TRJobAlert Notification to host that transfer
job is started or complete.
No
TrJobEvent Notification to host that a
transfer-related event has
occurred.
No
4.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 columns labelled REQ/IND and RSP/CONF link
the parameters to the direction of the message. The
message send by the initiator is called the “Request.”
When receiver terms this message the “Indication” or
the request. The receiver may then send a “Response,”
which the original sender terms the “Confirmation.”
The following codes appear in the REQ/IND and
RSP/CONF columns and 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 logical names but may be represented
by any data type excluding lists and structures.
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.
NOTE 4: To prevent the definition of numberous variables
named “XxxList”, this document adopts the convention of
referring to the list as “(List of) Xxx.” In this case, the
definition of the variable Xxx will be given, not of the list.
The term “list” indicates an ordered collection (or set) of zero
or more items of the same data type. List order is retained
from the message request to the response. For this document,
a list must contain at least one element unless zero elements
are specifically allowed.
TRJobCreate
The host requests that the equipment participate in a material transfer job.
Parameter REQ/IND RSP/CONF Description Form
TRJobName C - Host created identifier of the transfer job. This allows the
host to use a common name for the transfer job on each
participating equipment.
Text
(List of) AtomicSpec M - Specifications for the atomic transfer(s). Structure
TRJobID - M Equipment created ID of the transfer job. Unsigned Integer
(List of)
TRAtomicID
- M The equipment-created identifier of the atomic
transfer(s).* Order matches that given in the (List of)
AtomicSpec in the message req.
Unsigned Integer
TRStatus - M Reports acceptance or rejection of the transfer job. Structure
*All object IDs created by the equipment must be unique within that equipment for that object type. This includes TRJobID and TRAtomicID.
These IDs are used by the host to inquire about those objects.