semi合集-English.pdf - 第3216页
SEMI E127-0705 © SEMI 2003, 2005 17 initialization or runtime. In either case, the alarm cond ition shall be cleared before processing continu es. See ¶11.4.1. 4 for further det ail. 11.5.2.2 Unexpected Substrate Alarm —…
SEMI E127-0705 © SEMI 2003, 2005 16
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
i
”, 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
SEMI E127-0705 © SEMI 2003, 2005 17
initialization or runtime. In either case, the alarm condition shall be cleared before processing continues. See
¶11.4.1.4 for further detail.
11.5.2.2 Unexpected Substrate Alarm — This alarm is set during system initialization when substrates have been
detected, and the actual substrate count exceeds the number expected. See ¶11.4.1.4 for further detail.
11.5.3 SubstrateListUpdate — The SubstrateList attribute is a list of the ObjIDs for all substrates currently present
within the IMM module. Whenever a Substrate Object is created or deleted, this attribute is updated and an event
message is sent with the ObjID of the Substrate Object associated with the change.and whether it was added or
removed.
11.5.4 Table Storage Capacity Warning — A notification sent to the client when table capacity decreases below
TableStorageAlert and each time the storage further decreases.
11.5.5 Table Storage Capacity Overflow — Tables have been removed due to capacity overflow. Note: This is a
trigger for Transition 6 in the IMM Data Table state model, ¶14.2.
11.5.6 Event Variables — Certain variables shall be provided that are associated with certain events and contain the
values that were valid at the time the event occurred. For the IMM object, these variables are specified in Table 4.
The names of variables as specified shall be implemented exactly as text strings.
Table 4 Event Variables for IMM Object
Variable Name Description Type Event Comment
DateTime The date and time that the
event occurred.
Conforms to the
clock format in
SEMI E98.
All
Service Current state of Service
State Model.
Enumerated
IN SERVICE
OUT OF
SERVICE
All
SubstrateListChangeType Indicates the type of
change: addition or
deletion.
Enumerated
Addition
Deletion
SubstrateListUpdate
SubstrateID The last SubstrateID added
to or removed from the
SubstrateList attribute.
Text. SubstrateListUpdate
TableCount The number of tables
currently stored.
Integer. TableStorageCapacityWarning,
TableStorageCapacityOverflow
11.6 IMM Object Services
11.6.1 Table 5 defines the services specific to the Integrated Measurement Module. Message details are defined in
§19.
Table 5 IMM Object Services
Message Service Name Description Type Reqd
ChangeService Set the IMM in service or out of service. R Y
ClientConnect A request to become a Control Client or Data Client. R Y
ClientDisconnect A request to terminate the Client role. R Y
RequestRetentionConditions A request to send the rules and retention time for this client. R Y
SetAutoTableSend A request to set AutoTableSend on or off for this client. R Y
SetRetentionConditions The client sends a one or two level list of 0+ Retention Rules and an optional
minimum retention time.
R Y
TableRequest The client requests a specific table, or table subset. R Y
TableSend Used by the client to send a table or delete an existing table. Used by the
IMM to request to send a table to the client by the AutoTableSend capability.
R Y
SEMI E127-0705 © SEMI 2003, 2005 18
12 Substrate Transfer Path Object
12.1 Description
12.1.1 The Substrate Transfer Path object (STPO) manages the spatial envelope used for loading (receiving) and
unloading (sending) a substrate, along with all mechanisms used in effecting a physical transfer. It has one or more
Equipment Substrate Location objects for holding substrates after they are received and before they are sent. Each
Substrate Location can hold exactly one substrate when it is occupied. Substrate and Substrate Location objects are
defined in SEMI E90.
12.1.2 If substrates can be loaded into, and/or unloaded from, more than one substrate location, then each of these
locations shall be represented by a separate STPO object. This allows the Control Client to specify where it intends
to load or unload.
12.1.3 The STPO object allows the IMM to interact with an external substrate handler to transfer substrates to and
from a Substrate Port (a substrate location together with any necessary mechanisms), and also to exchange
properties of the Substrate Object being transferred.
12.1.4 A Substrate Transfer has two required parts, which may occur in either order: the substrate transfer and the
substrate information transfer. The transfer procedure consists of the messages and physical actions necessary to
effect the loading or unloading of a substrate to or from the Substrate Transfer Location. The exchange is not
complete until both parts have been successfully completed.
12.1.5 The minimum information required for processing is SubstrateID. Additional information is used to store as
context data in the IMM Data Table Objects discussed in §13. The method provided for obtaining the additional
information is the same as the method for providing SubstrateID.
12.1.6 The STPO shall provide two ordered lists of the sequence of text micro commands that are needed for
loading and for unloading a substrate to and from the Substrate Transfer Location. The Control Client may obtain
these lists on demand through the service XfrCmdListRequest. These micro commands are to be returned by the
Control Client in the XfrCommand service, one at a time, in the same order given, to effect a load or unload hand-
off. Micro commands are defined by the IMM supplier except for two that are required. Examples of micro
commands are given in the Load and Unload scenarios in ¶12.11. The two required micro commands are “Confirm
presence” and “Confirm Absence”, as specified in ¶12.11.2.3 and ¶12.11.3.3 respectively.
12.2 Object State Model
12.2.1 This section defines the Substrate Transfer State Model, which shows the behavior required for coordinating
the loading of a substrate to, and unloading from, the substrate location accessed by an external substrate handling
mechanism.
12.2.2 Figure 4 shows the diagram for the Substrate Transfer Path State Model.
SUBSTRATE TRANSFER PATH
READY TO
LOAD
READY TO
UNLOAD
1
2
ASSIGNED
BLOCKED
10
4
13
6
7
11
5
12
8 9
3
C
Figure 4
Substrate Transfer Path State Model