semi合集-English.pdf - 第2249页

SEMI E58-0703 © SEMI 1997, 2003 30 13.12 Production and Stan dby Substates — Transitions 2, 3, and 4 are ma de automaticall y by the equipm ent. User requests to chang e to PRODUCTIVE or STANDBY are accepted as methods o…

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.

SEMI E58-0703 © SEMI 1997, 2003

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.