semi合集-English.pdf - 第2250页

SEMI E58-0703 © SEMI 1997, 2003 31 be improperly or in completely installed, or it may be deliberately pushed past its limits. 4.1.30 Fault Detection in ENGINEERIN G — The equipment may also provide optio nal capability …

100%1 / 7923
SEMI E58-0703 © SEMI 1997, 2003
30
13.12 Production and Standby Substates — Transitions
2, 3, and 4 are made automatically by the equipment.
User requests to change to PRODUCTIVE or
STANDBY are accepted as methods of setting the
current substate of PRODUCTIVE or STANDBY.
However, within the MANUFACTURING superstate,
the equipment is responsible for determining when its
production criteria are satisfied.
4.1.16 Unless the equipment has information as
specified in this section concerning the appropriate
substate of PRODUCTIVE or STANDBY, then the
equipment shall select the appropriate default ARAMS
Substate Code (“1000” or “2000”, defined in Section
9.2).
4.1.17 To provide substate refinements important to
the user, the equipment shall remember the last
ARAMS Substate Code specified by the user for the
PRODUCTIVE state at Transition 10 and use this as a
default PRODUCTIVE substate value PrdState (Section
11.2) until a new value is specified. This value shall be
used for the new (current) ARAMS state/substate
information in the variable ARAMSState whenever the
equipment transitions to PRODUCTIVE.
4.1.18 The equipment normally uses the default code
for all transitions to STANDBY (“2000”). However,
when the user specifies an ARAMS Substate Code for
STANDBY with a substate, this value is to be used at
the next following transition to STANDBY at
Transition 2 (if the equipment then transitions to
STANDBY) or at the subsequent occurrence of
Transition 4 (if the equipment transitioned to
PRODUCTIVE at Transition 2).
4.1.19 This value is discarded (or reset to “2000”)
after a single use or upon any other transition that
intervenes between the Transition 10 where it is
specified and the time it is applied. This includes
intervening occurrences of a new Transition 10 as well
as of Transitions 11, 1, and others.
4.1.20 It is not important that the equipment provide
the user access to this value except when it is stored in
ARAMSState.
13.13 Equipment-Selected Substates — Equipment
may provide an optional capability to select substates of
PRODUCTIVE and STANDBY. In this case, the
equipment shall provide a user-configurable variable
SubstateSelect that enables and disables this capability
(Section 11.4.7).
4.1.21 Substate selection by the equipment is subject
to the requirements specified in Section 16.5. If the user
has selected a substate of PRODUCTIVE or
STANDBY, the equipment is restricted to that substate
or extensions of that substate. Note that a user-selected
substate of STANDBY is applied at most once.
4.1.22 The capability of selecting substates includes
the ability to select a new substate of the current state.
Transistions 12 and 13 shall be used for this purpose.
4.1.23 When transitioning to STANDBY, normally at
the completion of a process cycle, multiple standby
conditions may exist. For example, the equipment may
need both material and instructions from the host. In
general, a substate code of 2200 (SBY/No product)
shall take precedence over 2100 (SBY/No operator) and
2500 (SBY/No host).
4.1.24 If the standby condition represented by the
currently selected substate clears, then the equipment
shall either select a new substate of STANDBY
(Transition 12) or transition from STANDBY
(Transition 3).
4.1.25 Additional rules for determining substates may
be specific to a type of equipment and may be specified
by standards defining the capabilities for that type of
equipment.
4.1.26 The equipment supplier shall document the
prioritization of standby conditions used by the
equipment and of the basis for selecting substates of
PRODUCTIVE.
13.14 Equipment-Detected Exceptions — The
equipment may detect exceptions in any ARAMS state.
However, only those exceptions that occur during an
uptime state are of interest to the host.
4.1.27 Transitions 5 and 7 indicate the equipment
detects a fault condition and transitions to
UNSCHEDULED DOWNTIME from STANDBY and
PRODUCTIVE respectively. Transitions 6 and 8 are
provided to allow the equipment to return to its prior
state and are discussed in the following section.
4.1.28 When the equipment detects an exception
condition during PRODUCTIVE or STANDBY, so that
it is unable to perform its intended function, it shall
immediately transition to UNSCHEDULED DOWN-
TIME. The identifier of the associated alarm is stored
in DowntimeAlarm, and any description text associated
with that alarm is stored in DowntimeAlarmText. The
equipment supplier may provide additional descriptive
text that would be useful in diagnostics or analysis in
DowntimeData. In the case of the failure of a
component, attributes of that component (e.g., serial
number, installation date, lifetime cycles) is desirable.
4.1.29 If the equipment detects an exception condition
in non-uptime states, it shall not initiate a state change.
Exceptions occur for many reasons in non-
manufacturing states. For example, the equipment may
SEMI E58-0703 © SEMI 1997, 2003 31
be improperly or incompletely installed, or it may be
deliberately pushed past its limits.
4.1.30 Fault Detection in ENGINEERING — The
equipment may also provide optional capability of
transitioning to UNSCHEDULED DOWNTIME from
ENGINEERING (Transition 12) when it detects an
exception. Alarm-related variables in this case are
handled in the same way as described above.
4.1.31 The user shall be able to enable and disable this
capability with the user-configurable variable
EngInterrupt (Section 11.4.1).
13.15 Equipment-Initiated Recovery — Equipment-
initiated transitions 6, 8, and 13 from UNSCHEDULED
DOWNTIME are provided to allow equipment to
recover from an equipment-detected fault when the
operator intervenes, corrects the fault, and indicates the
process can be recovered. For Transition 6 to occur, the
equipment shall be able to resume processing without
degradation of the process or the material. The
equipment is responsible for ensuring the safety of
persons, material, and for the equipment itself.
4.1.32 Transition 13 is required if Transition 12 is
supported and is prohibited otherwise.
13.15.1 Automatic Recovery — Equipment may also
provide optional capabilities to recover automatically
from transient faults that clear spontaneously.
Automatic recovery at Transitions 6, 8, and 13 shall be
separately enabled and disabled using the user-
configurable variables PrdRecovery (Transition 6),
SbyRecovery (Transition 8), and EngRecovery
(Transition 13). Equipment is otherwise prohibited
from using Transitions 6, 8, or 13 to recover without
explicit operator approval.
4.1.32.1 Automatic recovery to manufacturing and
automatic recovery to ENGINEERING are regarded as
two separate capabilities.
4.1.32.2 If EngInterrupt (Section 11.4.1) is not sup-
ported or is disabled, then Transition 13 is prohibited.
14 Requirements for Compliance
This section summarizes the requirements for com-
pliance to ARAMS that are defined in this document.
14.1 Fundamental Requirements — Compliance to
ARAMS requires certain capabilities that are defined
by other standards.
14.1.1 Event Notification — A standard method for
notifying the host that an event of interest has occurred
and for providing specific information related to the
event.
14.1.2 Clock Services — Provision of a real-time
date/time clock with methods for setting and reading
the clock from the host.
14.1.3 Read-Only Data Access — A standard method
for the host to obtain the current values of selected
status variables and constants specified in Sections 11.2
and 11.3.
14.1.4 User-Configurable Data Access — A standard
method for the host to change the values of selected
variables defined in Sections 11.4 and 11.5.
14.1.5 Alarm/Exception Management — A standard
method for notifying the host of abnormal events and/or
conditions.
4.1.32.3 In addition to the requirements defined in
other standards, the following, defined by ARAMS, are
required for compliance to ARAMS:
14.1.6 ARAMS State Model — Conformance to the
behavior of the ARAMS state model defined in Section
8.3.
14.1.7 ARAMS State Transition Notification — Using
standard event report mechanisms (above), the host
shall be notified of all state transitions as described in
Sections 12 and 16.1.
14.1.8 ARAMS Substate Codes — Support for ARAMS
Substate Code formats, used for equipment variables
and service parameters defined in Section 9.
14.1.9 ARAMS Status Data — Support for all status
variables defined in Section 11.2.
14.1.10 ARAMS Constant Data — Support for all data
constants and for the user-configurable variable
EqpName defined in Sections 11.3 and 11.4.
14.1.11 ARAMS Event Report Data — Support for the
requirements of Section 12 requires either the provision
of pre-defined event reports or provision of the
Dynamic Event Report Configuration capability that
allows the host to dynamically modify the equipment
event reporting setup and define the content of reports
for each event.
14.1.12 Host State Change Request — Support for the
ARAMSStateChange service, defined in Sections 15.1,
15.2, and 15.5.
14.1.13 Estimation of Powerdown Time — Provision
of a method for maintaining PowerdownTime as an
estimate of the time of powerdown to an accuracy
within ± one minute.
14.1.14 ARAMS Behavioral Requirements — Con-
formance to all requirements in Section 16 except those
identified as optional or requiring optional variables.
SEMI E58-0703 © SEMI 1997, 2003
32
4.1.32.4 Table 14 lists the requirements for
fundamental compliance to ARAMS and the section
references to ARAMS or (where applicable) the
standards where these capabilities are defined. These
requirements shall all be satisfied for equipment to be
termed ARAMS-compliant.
Table 14 Table 14 Fundamental ARAMS
Requirements
Requirement Reference
Event Notification GEM 4.2.1.1 or ERS
Clock Services GEM 4.10 or CTMC 8.7
Read-Only Data Access GEM 4.2.2 or OSS 12.1
User-Configurable Data Access GEM 4.5 or OSS 12.1
Alarm/Exception Management GEM 4.3 or EMS
ARAMS State Model ARAMS 8.3
ARAMS State
TransitionNotification
ARAMS 12, 16.1
ARAMS Substate Codes ARAMS 9
ARAMS Status Data ARAMS 11.2
ARAMS Constant Data ARAMS 11.3, 11.4
ARAMS Event Report Data ARAMS 12, GEM
4.2.1.1, GEM 4.2.1.2.
Host State Change Request ARAMS 15.1, 15.2, 15.5
Estimation of Powerdown Time ARAMS 16.2
ARAMS Behavioral Requirements ARAMS 16 (all except
16.3.2, 16.7.4, 16.8.2)
4.2 Additional Capabilities — The following
capabilities are not required for fundamental
compliance to ARAMS. They are recommended for
equipment that provide a local operator interface and
are not expected from equipment such as individual
process modules of a cluster tool.
14.1.15 User-Configurable Powerup State —
Provision of the user-programmable variable
PowerupState, which allows the user to select either
STANDBY or UNSCHEDULED DOWNTIME as the
powerup state following powerdowns that occurred
during STANDBY. (See Section 16.3.2.)
14.1.16 User-Configurable Fault Recovery to
Manufacturing — Provision of user-programmable
variables, PrdRecovery and SbyRecovery, that allows
the user to enable or disable automatic equipment-
initiated recovery from faults that clear without user
intervention. (See Section 16.7.4.)
14.1.17 Accumulator Data — Support for the variables
defined in Section 11.5, together with access to this
data by the operator (Section 14.1) and the host, with
support for the ResetAccumulators service. (See
Sections 11.5 and 15.6.)
14.1.18 User-Generated ARAMS Substate Table(s) —
The ability to accept one or more sets of user-generated
ARAMS Substate Codes, as defined in ARAMS
Substate Tables, that may be selected by the user in a
request to change to a new state or substate. This
includes support of the TableSend and TableRequest
services and methods for operator access. (See Sections
10.3, 14.2, and 15.3.)
14.1.19 Equipment-Generated ARAMS Substate
Table(s) — Provision of a set of equipment-defined
ARAMS Substate Codes that can be selected by the
user in a request to change to a new ARAMS state or
substate. This includes support of the TableRequest
service. (See Sections 10.3 and 15.4.)
14.1.20 User-Generated Symptom Table(s) — The
ability to accept one or more user-defined ARAMS
Symptom Table, allows the operator to select a
symptom when requesting a transition to a new
ARAMS state, and the associated data. This includes
support for the TableRequest service and methods for
operator access. (See Sections 10.4, 14.3, and 15.3.)
14.1.21 Human Interface Requirements — Operator
access to ARAMS tables as defined in Sections 14.2
through 14.4. Where color is used, conformance to
color code in Section 14.5.
14.1.22 Equipment-Selected Substates — Support for
the user-configurable variable SubstateSelect (Section
11.4.5) allowing the user to enable and disable the
capability to select substates of PRODUCTIVE and
STANDBY. Documentation of the prioritization of
substate selection. (See Section 16.6).
14.1.23 User-Configurable Fault Detection in
ENGINEERING — Support for Transitions 12 and 13
(Section 16.7.4) and the user-configurable variable
EngInterrupt (Section 11.4.1) allowing the user to
enable and disable Transitions 12 and 13.
14.1.24 User-Configurable Fault Recovery to
ENGINEERING — Support for automatic recovery
(Transition 13, Sections 16.8.1 and 16.8.2) and the
user-configurable variable EngRecovery (Section
11.4.2) allowing the user to enable and disable
automatic recovery in Transition 13.
4.2.1.1 Table 15 provides the section references for
additional ARAMS capabilities.