semi合集-English.pdf - 第2568页

SEMI E90-0705 © SEMI 1999, 2005 8 8.5 Each Substrate Object instantiated on the equipment m u st maintain an inde pendent instance of t he Substrate Object State Model. When discrete an d unrelated state transitions occu…

SEMI E90-0705 © SEMI 1999, 2005 7

7.4 Identification of Substrate

7.4.1 Substrate shall be identified by substrate ID. There are options for assigning substrate ID to a substrate.

 When a carrier is used for loading substrates and the carrier is given its carrier ID, substrate IDs can be obtained

by utilizing the carrier ID and carrier substrate location. This standard will define the requirement for the

substrate ID assignment to the substrates in a carrier.

 Substrate ID may be read from the substrate directly by a substrate ID reader. The substrate ID read from the

substrate can be used for the identification.

 Substrate ID may be assigned by the user (i.e., host or operator). The substrate ID can be used for the

identification. This standard will define the service for registering substrates.

7.4.2 The recommendation of a particular option for assigning substrate IDs is not within the scope of this standard.

It must be selected based on the equipment design and applications.

8 Substrate Tracking Requirement

8.1 Compliance to Substrate Tracking Service (STS) requires that an implementation also provide certain

capabilities that are defined in other standards.

 STS requires compliance to SEMI E39 (OSS) for Substrate objects. The attributes of these objects may be

accessed through use of the GetAttr and SetAttr services.

 STS requires an event reporting capability. This capability may be satisfied by the Event Reporting capability in

SEMI E30 (GEM) or by SEMI E53 (ERS).

8.2 STS compliant equipment must implement capabilities defined in the following sections of this document:

 §9, Substrate Object Definition,

 §10, Substrate Location Object Definition,

 §12, Substrate Tracking Services,

 §13, Variable Data, if SEMI E53 is not implemented, and

 §11, Batch Location Object Definition, is an optional requirement.

8.3 When the equipment provides a substrate reader, the equipment shall implement an equipment constant to allow

the host to choose between using or not using this capability. The equipment constant: “SubstrateReaderEnabled” is

used to choose whether or not the equipment performs the reading of the substrate and use the Substrate Reading

Status state model. The equipment is responsible for creating the substrate objects. The substrate ID assigned to the

substrate object is the same as the one provided by the host in the ContentMap attribute or created by the equipment

using the following rule when the SubstID in the content map is not provided. The default substrate ID shall be

represented in text as the carrierID, a period and the substrate slot location. For example, if CarrierID = “xyz” and

substrate slot location = “5”, then the substrate ID would be = “xyz.05”.

8.4 All state transitions defined for the three state models specified in this document must be reportable via discrete

collection events as defined in ¶6.1, Harel State Model. The three state models are the Substrate Object State Model

(Figure 3), the Substrate Location State Model (Figure 4) and the Batch Location State Model (Figure 5).

8.4.1

The data in Table 15 (Variables Required for Substrate Object State Model Transitions) is required to be

available for the Substrate Object State Model transition collection events. Fixed buffer equipment must support

discrete state transitions for Substrate. Internal buffer equipment must support related state transitions that occur for

a group of Substrate objects. An equipment may support both discrete and related state transitions for Substrate.

8.4.2 The data in Table 16 (Variables Required for Substrate Location Object State Model Transitions) is required

to be available for the Substrate Location Object State Model transition collection events.

8.4.3 The data in Table 17 (Variables Required for Batch Location Object State Model Transitions) is required to be

available for the Batch Location Object State Model transition collection events.

SEMI E90-0705 © SEMI 1999, 2005 8

8.5 Each Substrate Object instantiated on the equipment must maintain an independent instance of the Substrate

Object State Model. When discrete and unrelated state transitions occur for Substrate Object models, each shall

trigger a separate collection event. However, when related state transitions occur for a group of Substrate Object

models (such as with internal buffer equipment material transfers), each model does not trigger a separate collection

event. Instead, a single collection event shall be triggered (for all related Substrate Objects in the group). The data

items defined in Table 15 are required to be valid for collection events triggered by state model transitions in the

following way:

8.5.1 These variables from Table 15 must be valid for collection events triggered by discrete state transitions:

 AcquiredID (equipment with substrate ID readers only)

 SubstID

 SubstIDStatus (equipment with substrate ID readers only)

 SubstBatchLocID (batch process equipment only)

 SubstDestination

 SubstHistory

 SubstSubstLocID

 SubstLotID

 SubstMtrlStatus

 SubstPosInBatch (batch process equipment only)

 SubstProcState

 SubstSource

 SubstState

 SubstType

 SubstUsage

8.5.2 These variables from Table 15 must be valid for collection events triggered by a group of related state

transitions:

 AcquiredIDList (equipment with substrate ID readers only)

 SubstIDList

 SubstIDStatusList (equipment with substrate ID readers only)

 SubstBatchLocIDList (batch process equipment only)

 SubstDestinationList

 SubstHistoryList

 SubstLocIDList

 SubstLotIDList

 SubstMtrlStatusList

 SubstPosInBatchList (batch process equipment only)

 SubstProcStateList

 SubstSourceList

 SubstStateList

SEMI E90-0705 © SEMI 1999, 2005 9

 SubstTypeList

 SubstUsageList

8.5.3 As an example of how the variables are constructed for related state transitions, the value of SubstIDList shall

be the list of SubstID data items that identify the Substrate Objects related by the collection event.

8.6 Each Substrate Location Object instantiated on the equipment must maintain an independent instance of the

appropriate Substrate Location Object State Model. Each Substrate Location Object shall trigger a separate

collection event for each state transition. The data items defined in Table 16 are required to be valid for collection

events triggered by each state model transition.

8.7 Each Batch Location Object instantiated on the equipment must maintain an independent instance of the Batch

Location Object State Model. Each Batch Location Object shall trigger a separate collection event for each state

transition. The data items defined in Table 17 are required to be valid for collection events triggered by each state

model transition.

9 Substrate Object Definition

9.1 A substrate is a base upon which a product unit is built in the manufacturing equipment. Wafers and flat panel

displays are examples of substrates. A substrate may be associated with a lot, which the factory uses for tracking

purposes.

9.1.1 The substrate object shall be created when the substrate is registered by the equipment. There are two

possible ways of registering the substrate.

(1) The substrate is registered by the equipment when the information for the carrier containing the substrate is

registered. The information required to create a substrate object must be provided with the carrier. However, the

specification of carrier management services is outside the scope of this standard. Substrate Tracking

implementations shall be consistent with the Carrier Management standard. For instance, if the Carrier Management

standard specifies the method of identifying the substrates in a carrier, then Substrate Tracking shall recognize those

identifiers.

(2) The substrate is registered when the substrate is transferred directly (not in a carrier) to the equipment by the

Create service defined in SEMI E39 to inform the equipment of this event.

9.2 Substrate Object State Model

9.2.1 A substrate has both a state indicating where it is located and a state indicating the progress of processing.

These states are represented by the SUBSTRATE TRANSPORT and the SUBSTRATE PROCESSING states,

which are concurrent substates of the SUBSTRATE State Model shown in Figure 3.

9.2.2 If the equipment provides a mechanism for reading substrates, then, the equipment shall include a state model

in parallel with the Substrate Transport and Substrate Processing States called “Substrate Reading Status” See

Figure 3 and Table 1 for additional requirements.

9.3 Substrate Object State Definitions

9.3.1 ABORTED — The process has been aborted during the processing. The substrate will require special

treatment.

9.3.2 AT DESTINATION — The substrate has been placed at its designated destination substrate location. The

substrate may have been placed at a carrier substrate location when the carrier is used to unload the substrate from

the equipment, or at an equipment substrate location when the substrate is to be removed by itself from the

equipment.

9.3.3 AT SOURCE — The state which the substrate is originally received. The substrate is held at carrier substrate

location when a carrier is used to supply the substrate.

9.3.4 AT WORK — The substrate has been taken from the original substrate location or destination substrate

location, and is traveling on intermediate equipment substrate locations. The substrate has been taken out of the

carrier and placed into the equipment when a carrier is used to supply the substrate.