semi合集-English.pdf - 第2247页

SEMI E58-0703 © SEMI 1997, 2003 28 Table 12 Table 12 ARAMSStateChange Service Parameter Req/Ind Rsp/Conf Description ObjSpec C - The object specifier, used to spec ify the owner of the target object. When omitted, the re…

100%1 / 7923
SEMI E58-0703 © SEMI 1997, 2003 27
Parameter Definition Form
TableRow A row of the table in terms of its elements
TableElem.
Structure, consisting of different table elements, following the
order of the column headers.
TableStatus Information concerning the success or
failure of the operation.
Structure consisting of TableAck and (List of) Status.
TableType Type of table. Text = “TableARAMSCode” or “TableARAMSSymptom”.
NOTE 1: ARAMS tables use only the general table attributes: number of rows, number of columns, and table length.
3.2 TableSend — The TableSend service is used to transfer or delete a table.
3.2.1 Table 10 defines the parameters for the TableSend service. A table that is not structurally valid shall be
rejected and discarded.
Table 10 Table 10 TableSend Service
Parameter Req/Ind Rsp/Conf Description
ObjSpec C - The object specifier, used to specify the owner of the target object. When omitted,
the receiver of the message is intended.
TableType M M Signifies the type of table to be sent.
TableID C C(=) Table identifier. Required for table type TableARAMSSymptom.
TableCmd M - Instructions about the table being transferred.
TableAttr (list of) M - The table’s attributes.
ColHdr (list of) M - Table column headers.
TableRow (list of) C - Table contents, organized by rows. Rows may or may not be ordered, depending on
the definition for a specific table type. Must be omitted when deleting a table.
TableStatus - M Information concerning the success or failure of the request.
3.3 TableRequest — The TableRequest service is used to request the service provider to send a table. A table that is
not structurally valid shall be discarded.
3.3.1 Table 11 defines the parameters for the TableRequest service.
Table 11 Table 11 TableRequest Service
Parameter Req/Ind Rsp/Conf Description
ObjSpec C - The object specifier, used to specify the owner of the target object. When omitted,
the receiver of the message is intended.
TableType M M Signifies the type of table to be sent.
TableID C C(=) Table identifier. Required for table type TableARAMSSymptom.
TableCmd M - Instructions about the table being transferred.
TableElem (list of) C - Row identifiers of requested rows. If omitted, entire table is requested.
TableAttr (list of) - M Table attributes.
ColHdr (list of) - M Table column headers. Omitted only if table for specified type and identifier does
not exist.
TableRow (list of) - M Table rows. Omitted only if table for specified type and identifier does not exist.
TableStatus - M Information concerning the success or failure of the request.
3.4 ARAMSStateChange — The ARAMSStateChange service is sent to the service provider to request a change to
a new ARAMS state/substate.
3.4.1 Table 12 defines the parameters for the ARAMSStateChange service.
SEMI E58-0703 © SEMI 1997, 2003
28
Table 12 Table 12 ARAMSStateChange Service
Parameter Req/Ind Rsp/Conf Description
ObjSpec C - The object specifier, used to specify the owner of the target object. When omitted,
the receiver of the message is intended.
ARAMSCode M - New ARAMS state/substate requested.
SymptomID C - ARAMS Symptom ID. Optional.
SymptomText C - Symptom description. Optional.
RequestStatus - M Information concerning the success or failure of the request.
3.5 ResetAccumulators — The ResetAccumulators service is sent to the service provider to request that the set of
accumulators defined in Section 11.5 be reset.
3.5.1 Table 13 defines the parameters for the ResetAccumulators service.
Table 13 Table 13 ResetAccumulators Service
Parameter Req/Ind Rsp/Conf Description
ObjSpec C - The object specifier, used to specify the owner of the target object. When omitted,
the receiver of the message is intended.
RequestStatus - M Information concerning the success or failure of the request.
4 ARAMS Behavioral Requirements
This section specifies the behavior required for
ARAMS compliance.
13.8 ARAMS State Transitions — ARAMS compliance
requires that the equipment be capable of Transitions 1
through 11 in Table 1, with the exception of Transition
9. Transitions 12 and higher are optional.
4.1.1 Transition 9 is required only of equipment that
puts itself in a preventive maintenance mode based on
one or more internally monitored parameters, such as a
cycle counter. Transition 9 specifies that such a
transition takes place from STANDBY to
SCHEDULED DOWNTIME only. For equipment
without this feature, Transition 9 never occurs.
4.1.2 The equipment is required to provide the
capability to report to the host each time a state
transition occurs and to include data related to that
transition in these reports. Transition data included in
these reports allows the factory to calculate the amounts
of time spent in the different states.
4.1.3 At all transitions except Transition 10, when a
manufacturing state is specified, and Transition 11, the
current value of ARAMSState is stored in
PrevARAMSState and the ARAMS Substate Code
specified is then stored in ARAMSState. A user
selection of a specific manufacturing state is discussed
in Section 16.5 below.
4.1.4 For all equipment-initiated transitions, except as
specified in Sections 16.5 and 16.6, the equipment shall
use an ARAMS Substate Code representing the default
for that state and shall not select a substate.
4.1.5 DowntimeAlarm and DowntimeAlarmText are
set only for equipment-initiated transitions to
SCHEDULED DOWNTIME and UNSCHEDULED
DOWNTIME. For all other transitions, these variables
are cleared.
4.1.6 If the equipment supports ARAMS accumulators
(Section 11.5), then the time spent in the previous state
is calculated and the appropriate accumulator is updated
at this time.
13.9 Powerup Entry — The ARAMS State Model
becomes active during or after initialization following a
powerup or reset when Transition 1 occurs. The state
entered at Transition 1 (the default entry state) depends
upon the ARAMS state that was last active before the
powerdown or reset occurred. This is determined by the
ARAMS Substate Code stored in ARAMSState
(Section 11.2.4). If this value is not a valid ARAMS
Substate Code as defined in Section 9.4, then the
default entry state is NON-SCHEDULED TIME.
4.1.7 At Transition 1, if the value in Powerdown-Time
does not represent a valid date and time, it shall be set
to a string of all zeroes. The value stored in
PowerdownTime is then stored in LastPowerdown to
preserve the estimate of the timestamp of the last
powerdown or reset. PowerdownTime is next set to the
current date and time, and periodic updating of Class 5
variables is enabled.
SEMI E58-0703 © SEMI 1997, 2003 29
4.1.8 Normal communications to both operator and
host are unavailable from powerdown to a point within
or following system initialization. It is recommended
that initializations affecting communications with the
host precede initialization of the ARAMS State Model,
to allow an event report to be sent to the host on
Transition 1. It is highly desirable to the host to receive
an event report for Transition 1. However, it is not
required for ARAMS compliance.
4.1.9 Transition 11 never generates an event report.
13.10 Powerup and Powerdown States — The
ARAMS state entered at Transition 1 is the default or
powerup entry state for the ARAMS State Model. The
powerdown state is the state that was active at
Transition 11 and is determined by the value stored in
ARAMSState at the time of Transition 1.
4.1.10 If the value in ARAMSState indicates any non-
manufacturing state (ENGINEERING, SCHEDULED
DOWNTIME, UNSCHEDULED DOWNTIME, or
NON-SCHEDULED TIME), it is regarded by the
factory as continuing in that state both during the time it
is powered off and at Transition 1. The powerup entry
state is the same as the powerdown state.
4.1.10.1 If the equipment is in PRODUCTIVE or
STANDBY and is powered off, it is regarded by the
factory as in UNSCHEDULED DOWNTIME from the
time of the powerdown, through any subsequent
powerup, and until it is specifically put into a different
state by the user. The ARAMS powerup entry state
either is UNSCHEDULED DOWNTIME or is
determined by an optional variable PowerupState
(Section 11.4.2) to be either UNSCHEDULED
DOWNTIME or STANDBY.
4.1.10.2 If the ARAMS state prior to powerdown
cannot be determined (e.g., if it has never been set or is
invalid), the state entered after powerup is NON-
SCHEDULED TIME.
4.1.10.3 Time-in-state calculations for the powerdown
state assume that any transition to a new state occurs at
the time of powerdown, re-boot, or reset.
13.10.1 PowerupState — PowerupState, where
supported, shall be configurable by the user to specify
either UNSCHEDULED DOWNTIME or STANDBY
as the powerup entry state after a powerdown has
occurred from PRODUCTIVE or STANDBY. The
impact of loss of power has different effects on
different types of equipment. An entry state of
STANDBY allows those types of equipment that do not
have safety or setup concerns to be powered off and on
and returned to manufacturing. PowerupState contains a
text character of either “2” (STANDBY) or “5”
(UNSCHEDULED DOWNTIME) and has an initial
default value of “5”. If the value in PowerupState is
neither “2” nor “5”, then it shall be set to “5”.
13.11 User-Initiated State Change Requests — The
user may request an ARAMS state change at any time.
The host requests a state change through the ARAMS
message ARAMSStateChange (Section 15.5),
specifying an ARAMS Substate Code or the special
manufacturing code “0000”. The operator uses the
human interface to request a state change, and this shall
result in the specification of a valid ARAMS Substate
Code (Section 9.4) or of the manufacturing code.
4.1.11 The equipment shall deny the request if the
specified code is not valid or if the user specifies a code
for manufacturing when any exception condition exists
that would prevent the equipment from performing its
intended function.* Otherwise, Transition 10 occurs,
regardless of whether the new ARAMS Substate Code
is the same or different from the value in ARAMSState
representing the current state.
* NOTE: See SEMI E10 definitions.
4.1.12 If the user specifies a manufacturing state, and
the equipment accepts the state change request, then
Transition 10 occurs and is immediately followed by
Transition 2. Transition 2 always occurs in conjunction
with Transition 10 and does not generate a report
separately from Transition 10. It is regarded as an
extension of Transition 10 where the equipment
determines the specific state/substate based on its
internal status at the time.
4.1.13 At Transition 2, the equipment determines the
new state as either PRODUCTIVE or STANDBY,
based on its internal condition at the time. It is
prohibited from transitioning to PRODUCTIVE unless
its productive criteria have been met and it is busy
performing its intended function. The current value of
ARAMSState is moved to PrevARAMSState, and the
ARAMS Substate Code for the new state is placed in
ARAMSState. The event report associated with
Transition 10 shall be generated after the equipment has
determined the new state at Transition 2 and updated
the appropriate variables.
4.1.14 The user may optionally specify a symptom
identifier and text, which are saved in the variables
SymptomID and SymptomText (Section 11.2). If not
provided, SymptomID is set to zero and SymptomText
is set to a zero-length text string. The equipment does
not otherwise set these values.
4.1.15 The user also may optionally enter comments
that are stored in DowntimeData when selecting a
transition to UNSCHEDULED DOWNTIME from a
manufacturing state. Otherwise, DowntimeData is set
to a zero-length text string.