semi合集-English.pdf - 第2252页

SEMI E58-0703 © SEMI 1997, 2003 33 Table 15 Table 15 Section References for A dditional ARAMS Capabilit ies Capability Section Reference User-Configurable Powerup State ARAMS 11.4.4, 16.3.2 User-Configurable Fault Recov …

SEMI E58-0703 © SEMI 1997, 2003

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.

SEMI E58-0703 © SEMI 1997, 2003 33

Table 15 Table 15 Section References for Additional ARAMS Capabilities

Capability Section Reference

User-Configurable Powerup State ARAMS 11.4.4, 16.3.2

User-Configurable Fault Recovery ARAMS 11.4.2, 11.4.5, 11.4.6, 16.8.2

Accumulator Data ARAMS 11.5, 15.5

User-Generated ARAMS Substate Table(s) ARAMS 10.1, 10.2, 10.3, 14.3, 15.3

Equipment-Generated ARAMS Substate Table(s) ARAMS 10.1, 10.2, 10.3, 15.4

User-Generated ARAMS Symptom Table(s) ARAMS 10.1, 10.2, 10.4, 14.3, 14.4, 15.3

Human Interface Requirements ARAMS 14.2, 14.3, 14.4, 14.5

Equipment-Selected Substates ARAMS 11.4.7, 16.6

User-Configurable Fault Detection in ENGINEERING ARAMS 11.4.1, 16.7, 16.7.4

User-Configurable Fault Recovery to ENGINEERING ARAMS 11.4.2, 16.8

Human Interface Requirements ARAMS 14, 14.1, 14.2.

14.1.25 Human Interface Requirements — Operator access to ARAMS data and state change, defined in Sections

14, 14.1, and 14.2.

14.2 Requirements for Compliance — Table 16 provides a checklist for ARAMS compliance.

Table 16 Table 16 ARAMS Compliance Statement

Fundamental ARAMS Requirements Implemented ARAMS Compliant (See NOTE 1.)

Event Notification ❏ Yes ❏ No ❏ Yes ❏ No

Clock Services ❏ Yes ❏ No ❏ Yes ❏ No

Read-Only Data Access ❏ Yes ❏ No ❏ Yes ❏ No

User-Configurable Data Access ❏ Yes ❏ No ❏ Yes ❏ No

Alarm/Exception Management ❏ Yes ❏ No ❏ Yes ❏ No

ARAMS State Model ❏ Yes ❏ No ❏ Yes ❏ No

ARAMS State Transition Notification ❏ Yes ❏ No ❏ Yes ❏ No

ARAMS Substate Codes ❏ Yes ❏ No ❏ Yes ❏ No

ARAMS Status Data ❏ Yes ❏ No ❏ Yes ❏ No

ARAMS Constant Data ❏ Yes ❏ No ❏ Yes ❏ No

ARAMS Event Report Data ❏ Yes ❏ No ❏ Yes ❏ No

Host State Change Request ❏ Yes ❏ No ❏ Yes ❏ No

Estimation of Powerdown Time ❏ Yes ❏ No ❏ Yes ❏ No

ARAMS Behavioral Requirements ❏ Yes ❏ No ❏ Yes ❏ No

Additional Capabilities Implemented ARAMS Compliant (See NOTE 2.)

User-Configurable Powerup State ❏ Yes ❏ No ❏ Yes ❏ No

User-Configurable Fault Recovery to Manufacturing ❏ Yes ❏ No ❏ Yes ❏ No

Accumulator Data ❏ Yes ❏ No ❏ Yes ❏ No

User-Generated ARAMS Substate Table(s) ❏ Yes ❏ No ❏ Yes ❏ No

Equipment-Generated ARAMS Substate Table(s) ❏ Yes ❏ No ❏ Yes ❏ No

User-Generated ARAMS Symptom Table(s) ❏ Yes ❏ No ❏ Yes ❏ No

Equipment-Selected Substates ❏ Yes ❏ No ❏ Yes ❏ No

User-Configurable Fault Detection in ENGINEERING ❏ Yes ❏ No ❏ Yes ❏ No

User-Configurable Fault Recovery to ENGINEERING ❏ Yes ❏ No ❏ Yes ❏ No

Human Interface Requirements ❏ Yes ❏ No ❏ Yes ❏ No

NOTE 1: Do not mark YES unless all fundamental ARAMS requirements are implemented.

NOTE 2: Additional capabilities may not be marked ARAMS-compliant unless all fundamental ARAMS requirements are implemented.

15 ARAMS States for Multi-Module Equipment

4.3 The preceding sections define how ARAMS is to

be supported by simple equipment. Simple equipment

includes equipment with at most one process chamber,

and a single process capability, where individual

modules are not treated separately from the equipment.

NOTE 22: Process capability, in this context, refers to the

factory’s manufacturing process. Equipment with more than

one process capability may be used in different ways at

different steps, typically through different process recipes.

Such equipment may be “available” for one process but not

for another. This type of complexity is neither addressed nor

affected by SEMI E10 or by ARAMS.

4.4 This section addresses the application of ARAMS

to complex equipment, including modular equipment

where individual modules may be in different ARAMS

states/substates. Complex equipment includes cluster

tools and any other type of equipment that is organized

into separate subsystems that can be addressed

individually. In this case, it is advantageous for each

module or subsystem to be given its own ARAMS state

model. In addition, the overall equipment system itself

has an ARAMS state model. This situation is illustrated

in Figure 6.

4.5 The complexities of possible interactions between

ARAMS states of the individual modules and the

ARAMS state of the cluster tool as a whole are beyond

the scope of this document. The following approach is

recommended:

• Each module complies to fundamental

requirements for the ARAMS state model, data

variables, and message services.

• The integrated cluster tool complies to

requirements for the ARAMS state model, data

variables, and message services.

• The set of all the ARAMS models above are

simultaneously active, as represented in Figure 6.

• The relationships between the ARAMS state for

the cluster tool and the ARAMS states for the

individual modules are user-configurable wherever

possible. (Certain relationships between the cluster

and critical modules, such as central wafer handler

or central load lock, may not be configurable: e.g.,

if the critical module is down, the cluster is down.)