semi合集-English.pdf - 第3214页

SEMI E127-0705 © SEMI 2003, 2005 15 11.3.4.2.1 Once all retention rules have been satisfied fo r a given table for all clients, the IMM may delete the table at its own discret ion based on i nternal requirement s that ar…

SEMI E127-0705 © SEMI 2003, 2005 14

Attribute Name Definition Access Reqd Form

EventList List of event name/event number pairs. RO Y List of text/integer pairs.

RetentionRules Retention Rules supported by the IMM. RO Y List of 0+ conditions.

Service Current status of the Service State Model. RO Y Enumerated:

InService

NotInService

SubstrateList A list of zero or more ObjID for all substrates

currently within the IMM, regardless of

location.

RO Y List of 0+ text.

TableCapacity Indicates maximum number of tables that may

be stored.

RO Y Integer.

TableCount Indicates number of tables currently stored. RO Y Integer.

TableStorageAlert Remaining table storage capacity. Either the

number of additional tables that can be stored

(integer) or the remaining percentage of total

capacity (floating point) available. When

remaining capacity reaches this value, the

Table Storage Capacity Warning event

message is sent.

RO Y Integer or floating point

IMM

EventList: list of text/integer pairs

RetentionRules: list of retention rule

Service: enumeration

SubstrateList: list of text

TableCapacity: integer

TableCount: integer

TableStorageAlert: integer or float

ChangeService

ClientConnect

ClientDisconnect

RequestRetentionConditions

SetAutoTableSend

SetRetentionConditions

TableRequest

TableSend

Figure 3

IMM Object

11.3.2 The attribute EventList identifies all of the errors that may be generated by the IMM object. Each such event

shall have both a descriptive name and a numeric identifier, each of which shall be unique within the EventList list.

11.3.3 The attribute TableCapacity identifies the maximum number of tables that the IMM is capable of storing.

The client may use this information for determining its own retention rules.

11.3.4 Retention Conditions — A question of concern to the IMM is the method of determining when a data table is

no longer required. Each client is able to select individual conditions for retaining raw data and conversion tables.

These conditions are the client-selected RetentionRules.

11.3.4.1 The IMM has a RetentionRules attribute that lists the specific retention rule elements supported by the

IMM (see Table 3 for definitions of retention rule elements). An empty (null) list signifies that there are no

retention rules that can be met to cause the table to be either deleted or retained.

11.3.4.2 The IMM maintains a list of rules for each client. This is a single level or two level list of rules from the

RetentionRules list. This list is available on the RequestRetentionRules request by the client and is not publicly

available as an attribute.

SEMI E127-0705 © SEMI 2003, 2005 15

11.3.4.2.1 Once all retention rules have been satisfied for a given table for all clients, the IMM may delete the table

at its own discretion based on internal requirements that are outside the scope of this standard. The IMM is

responsible for managing both its storage space and those tables that do not need to be retained for any client.

11.3.4.2.2 As a single level list, when any item list is satisfied, the table may be deleted (a logical OR condition).

11.3.4.2.3 If one or more conditions need to be satisfied before a table may be deleted (a logical AND condition),

the items should appear as a list of RetentionRules that occupy one element of the top level list. For instance, if the

retention rule is that conditions A and B both need to be met, or condition C must be met, then the

DefaultDataRetention rule is a two element list with one element being a 2 item list of A and B and the other is just

condition C:

(A,B), C

11.3.4.2.4 An empty (null) list is equivalent to a “No Retention Rule” condition.

11.3.4.2.5 Actual representation of this list is dependent upon the communication protocol used.

11.3.4.3 Until or unless set by the client, the client’s retention rule is a zero element list, signifying that no retention

rule has been set.

11.3.4.4 Except when required by automatic rollover (¶11.3.5.2), no IMM Data Table Object shall be deleted until

all client retention rules have been satisfied.

11.3.4.5 The definitions of individual standard retention rule elements are provided in Table 3. Additional rules

may be defined in the future. All of the individual rules shall be integers, where a non-value indicates that this rule

is enabled. Otherwise it is disabled. The default value for each element is zero.

Table 3 Retention Rule Element Definitions

Retention Rule Definition

After Transfer The table may be deleted after it has been sent to the client. Any non-zero value indicates that this rule is

enabled. A value of zero disables it.

Client Delete If ClientDelete is non-zero, tables are retained until deleted by the client. However, each time the table

capacity drops below the value in ClientDelete, the TableStorageCapacityWarning event is generated and

sent to the client, so the client can then delete tables no longer needed. If the client fails to delete sufficient

tables, then the Automatic Rollover deletes the oldest tables as described below.

Maximum Tables

Stored

This rule sets a value for the maximum number of tables that should accumulated before Automatic Rollover

takes effect and the oldest table(s) are deleted when there is insufficient room to store a new table.

Maximum value for this rule is Table Capacity – 1.

RetentionTime The value in RetentionTime indicates the maximum length of time, in hours, that a table should be retained

in storage. The table may be deleted after this period of time has expired. Any internal timers used are not

visible to the client.

11.3.5 Table Storage Management — All tables shall be stored in non-volatile storage once they have been

completed.

11.3.5.1 Calibration Table — The latest instance of Calibration Table shall always be retained in storage.

11.3.5.2 Automatic Rollover — In the event that there is not enough storage capacity remaining to store a new table,

then the oldest tables of the same type as the new table (for either raw data or converted data) shall be deleted, one at

a time, until there is room to store the new table, regardless of the presence or absence of retention rules.

NOTE 4: The size of Raw Data Table Objects and Converted Data Table Objects may be significantly different.

11.3.5.3 TableStorageAlert is a constant determined by the supplier that represents either the approximate number

of tables (total) that may still be stored, or a percentage of total remaining storage capacity (TableCapacity). When

the remaining capacity drops to the level indicated by TableStorageAlert, a Table Storage Capacity Warning event is

sent (¶11.4.5).

11.4 System Initialization — Whenever the Integrated Measurement Module is powered on or reset, it goes through

a system initialization before it is acknowledges communications with, or establishes, any potential client.

Initialization activities include both software initialization and hardware initialization. On the completion of

initialization, the IMM is in a known condition, and the following requirements have been satisfied:

 All state models have been set to their entry state,

 Communications have been initialized,

 The physical status of the IMM is known,

 The absence or presence of substrates is known,

 Exceptions, including all alarm conditions, have been determined,

 No process jobs are defined,

 No clients have been established, and

 All internal equipment substrate locations have been checked for the presence of substrates, and the total count

of substrates detected has been compared with the number expected.

11.4.1 Substrate Count Discrepancy

11.4.1.1 The determination of expected substrate count requires that sufficient information about actual count must

be maintained in non-volatile memory during run-time so that is available to accurately determine expected count

during system initialization. For example:

 The content of the IMM attribute SubstrateList is saved in non-volatile memory whenever it is updated, and

expected count is determined by the number of valid entries in the list, or

 A list of occupied internal substrate locations is retained in non-volatile memory each time any one is updated,

and the expected count is determined by the number of valid entries in the list, or

 A simple count of the number of current substrates is retained in non-volatile memory.

11.4.1.2 If both the expected count and the actual count are zero, and there are no other errors or alarms, then the

IMM Service state is IN SERVICE, and the IMM EPT state is IDLE.

11.4.1.3 If both the expected count and the actual count are equal and non-zero, then the IMM Service state is OUT

OF SERVICE, and the IMM EPT state is BLOCKED. In this case, the substrates are assigned temporary identifiers

of “unknown

”, where i = 1,…, number of actual substrates detected. The substrates shall be unloaded in an orderly

manner. When all substrates have been unloaded, and all alarms are cleared, the IMM Service state changes to IN

SERVICE, and the IMM EPT state changes to IDLE

11.4.1.4 If the expected count is greater than the actual count, then a Missing Substrate alarm is set. If the expected

count is less than the actual count, then an Unexpected Substrate alarm is set. In either case, the IMM remains OUT

OF SERVICE and BLOCKED until the alarm condition is cleared. The IMM may provide a method for a

maintenance technician to determine if the “lost substrate” is actually present or if the “unexpected substrate” is

actually present (for example, the physical module may provide a view plate). and to indicate whether or not it is

safe to unload. Such methods are beyond the scope of this standard. Note that sensor errors can result in an apparent

loss or gain that is not real. Note also that it may be possible for a maintenance technician to interact with the IMM

as a “control client”.

11.5 IMM Events and Alarms

11.5.1 In addition to the special events and alarms described below, all state transitions shall be capable of

triggering an event, including all state models required by other standards required by IMMC.

11.5.2 Alarms — Various alarms caused by hardware-specific malfunction may occur at any time, including those

detected by the Substrate Transfer Path Object (STPO). In addition, alarms may be caused by a discrepancy

between actual and expected substrate counts.

11.5.2.1 Missing Substrate Alarm — This alarm is set whenever a substrate is no longer detected. The substrate is

either broken (and must be manually removed) or a sensor has failed so that it can no longer detect a substrate. This

condition shall cause the IMM Service state to set to OUT OF SERVICE and the IMM EPT state to be set to

BLOCKED so long as this condition exists. This condition may occur at any time, either during system