semi合集-English.pdf - 第1642页

SEMI E38-1296 © SEMI 1995 , 1996 31 CTMC Event Repo rting Services to attach the data of interest directly to the module collection event. Variable Dat a Coll ection/Stat us Data Collecti on — Again, the cl uster m ust t…

SEMI E38-1296 © SEMI 1995, 1996 30

host communication standards to cluster-based

equipment.

Below, each GEM capability will be addressed

separately, followed by a look at capabilities which

GEM does not cover. The capabilities are taken in

roughly the order given by SEMI E30 (GEM) table of

contents.

Communications State Model/Establish

Communications — The Communications State Model

is related to the ability to communicate. It is

independent of the functionality offered by the

equipment. There is no conflict with the cluster tool

supporting this GEM capability.

Control State Model — The control state model

assumes a single operator interface at the equipment. A

cluster tool is expected to supply such an interface

connected to the cluster controller.

However, there is a potential disconnect with attached

modules which supply user interfaces. Since CTMC

does not provide anything similar to the control state

model at this time, the cluster controller has no control

over access to these separate user interfaces, nor even

any knowledge of what might be happening. In this

situation, the cluster controller cannot guarantee

compliance to the control state model.

To assure GEM compliance, it is recommended that a

module request and receive closure of all control-

related service connections before allowing use of its

local operator interface in a control mode. This assumes

the use of the communication environment as defined in

SEMI E38.1.

Equipment Processing States — GEM specifies that

there be a processing state model. The model given in

the document is only an example, which shows the

approximate depth needed and suggests a form. The

example applies to the classic single chamber, single-

process machine. Thus, it may not be directly

applicable to a cluster tool. The cluster tool is required

to provide a processing state model, but the form should

match the cluster tool's function. The Plasma Etch

Specific Equipment Model (document available from

SEMI) suggested one way to model a multi-chamber,

multi-process job machine.

Data Collection — Data collection is a combination of

several different capabilities. Each will be discussed in

turn.

There is also a high-level issue with data collection.

GEM assumes a flat address space. That is, it assumes

that the smallest granularity of object is “equipment.”

The equipment has attributes. Some attributes are read-

only (Status Variables). Some have read/write access

(Equipment Constants). There are a few read-only

attributes which are valid only at certain times

(DVVALs).

Cluster tools do not fit this model well. The CTMC was

based on a model which includes a hierarchy of objects

which contain (or control) other objects. The CTMC

requirements are a subset of that model and include a

cluster controller (which does not have to be a single

entity), attached modules, transport module, and

specific objects associated with the services. Thus, to

request information about the processing of a wafer in a

process module, the attributes of the process job must

be accessed. The chain then includes Cluster

Controller->Process Module->Process Job->Job

Attribute. It is quite a challenge to present this attribute

as SVID #532678. And yet, this is what must be done.

The cluster controller should provide a flat name space

from which to access critical module data. Object

services with scopeing capabilities may also be

supported through the host interface, but if used, this

would be an extension to the host's GEM interface. The

data collection categories below give more detail on the

challenge and possible solutions.

Event Notification — Many of the events of interest to

the host actually occur at the attached modules (e.g.,

“Etch step complete for wafer x”). The cluster

controller is responsible for assigning each of these

events a unique CEID. There are two challenges: (1) to

assure uniqueness of events from duplicate modules,

and (2) to provide a scheme whereby the host can

determine the source of the event. Embedding a module

number within the CEID is one solution which has been

used to address both challenges. For instance, the

highest order byte of a four-byte integer might contain

the module ID.

Dynamic Event Report Configuration — The host must

be able to attach the information of interest to the event

notifications. The cluster controller is responsible for

providing access to the attributes of the cluster

modules. It is also responsible for assuring that the data

contained in the event reports is representative of the

state of the cluster at the time the event occurred.

There are three sources of data for the event reports.

1. Cluster Controller: Data which is local to the

cluster controller may be accessed directly.

2. Module (not source of collection event): This data

must be polled unless a data trace for the attributes

of interest is in progress.

3. Module (source of collection event): This data

tends to be most closely related to the event and

thus the most time-critical. While polling and data

trace may be used in this case, it is better to use the

SEMI E38-1296 © SEMI 1995, 199631

CTMC Event Reporting Services to attach the data

of interest directly to the module collection event.

Variable Data Collection/Status Data Collection —

Again, the cluster must take measures to present a flat

address space. See various discussions above.

Limits Monitoring — Clearly, most variables which

would be of interest for limits monitoring reside in the

cluster modules. The CTMC does not provide specific

services for configurable limits monitoring. A module

may provide for some limits checking via “limits”

attributes of objects which may be set via object

services. Notification of excursions beyond limits

would be via exceptions and/or collection events. If this

method is not available, the cluster controller would

have to institute a data trace on the attribute of interest

and then itself perform the limits checking activity.

The time period of the trace would be crucial to

assuring that short-term excursions are not missed.

Trace Data Collection — Trace data collection maps

well from GEM to CTMC. In fact, the CTMC services

in this area are a superset of the GEM functionality.

On-Line Identification — At first glance, this seems to

be an easy requirement to meet. However, the model

number and software revision included in the message

are ambiguous on a cluster with separate model

numbers for each module (and the cluster controller

itself) and separate software releases running on each.

The purpose of these data items is to allow the host to

determine when the equipment has been changed in

such a way that it may no longer be compatible with the

host software. At a minimum, the data items should

indicate a change to the cluster controller software (e.g.,

a new revision of the software, or a significant

reconfiguration such as the addition of a new module).

Alarm Management — GEM alarm management is a

subset of the functionality of the CTMC exception

services. Any exception message from a module can,

where desired, be translated into a GEM-compliant

alarm message. The set of CTMC exceptions is a

superset of GEM alarms. GEM alarms are of a serious

nature and expect human intervention to be required.

The CTMC extends this set to include problems which

the controller may be able to solve, and provides for

modules to suggest appropriate recovery actions.

Those CTMC exceptions which fall into the GEM

alarm category should be passed on via the GEM Alarm

capability. Exceptions which are not GEM alarms

should be reported only as events.

Remote Control — Cluster tools need to be able to

handle multiple tasks simultaneously. Most need to

handle multiple lot or batch jobs at once. GEM's

support for (process) job control is minimal. The

implicit assumption in GEM is that only one job at a

time will occur on a machine. It provides for a

“START” command, collection events when the job is

actually started and when it finishes, and also job

control commands (e.g., PAUSE, RESUME, ABORT,

STOP). What GEM lacks is differentiation of one job

from another (e.g., a job ID).

However, the GEM remote command message does

provide for parameters. A cluster tool may be able to

implement a scheme which is similar to that defined by

the Process Management Services. For instance, a “job

ID” parameter may be included in all job-related

messages. Thus, the equipment would set a job ID in

the “Start” or the “PP-Select” message (whichever first

refers to the job), and would then refer to that ID in any

subsequent job control commands. The job ID could

also be available as a data value in collection event

reports. While it might be preferable to have the

equipment assign the job ID, this scheme may be

workable.

Equipment Constants — Again, the flat address space

issue applies. (See the Data Collection section above.)

Process Program Management — The CTMC uses

Recipe Management Services (RMS) to manage recipes

internal to the cluster. GEM's processing services is a

different mechanism. The two can be made to interact,

but the combination is not ideal. It is possible for the

cluster to translate a “recipe” to a “process program”

for communication with the host. However, if a recipe

is created or modified at the host and then downloaded,

the editor at the host must be compatible with RMS

concepts, and care must be taken to maintain the

integrity of the RMS system.

Material Movement — GEM requires only collection

events when material is received or sent. A cluster can

easily satisfy this requirement.

Equipment Terminal Services, Error Messages, and

Spooling — Equipment Terminal Services, Error

Messages, and Spooling are in the domain of the cluster

controller. Cluster modules do not provide these

functions, nor do they contribute to the cluster

controller's delivery of the services.

Clock — A key purpose of clock is to allow the host to

determine ordering of events from an equipment. The

cluster controller should ensure that this need is met.

The cluster should attempt to report consistent time

relative to its modules. Also, when the factory host sets

the time on the cluster, the cluster controller should

resynchronize the time on its modules. There should be

no compatibility problems in this area.

Figure 20

Typical Operating Scenario

A1-2 Typical Operating Scenario

The purpose of this section is to give an example of a

typical operating scenario that will illustrate the various

services being used to perform cluster tool control

functionality. This operating scenario is NOT intended

to be the only scenario to be implemented in a

standards-compliant cluster. The intent is to provide

guidance in navigating the various services standards.

An exhaustive use of Object Services and Exception

Management Services will not be done since these two

areas tend to be very application-specific.

This scenario concentrates on the material processing,

material movement aspects of the cluster-specific

services.

The operating scenario shown in Figure 20 will be

given in the form of a communication timing diagram

with messages being sent between the various cluster

tool components and will be indicated in the following

manner:

ServiceGroup_ServiceName.Request or Response

(Service Parameters)

Example: TRJobCreate.Req(...)

• TR is the service group that contains the service,

the material movement services.

• JobCreate is the service being used to cause

communication to take place between two cluster

tool components. Specifically, this service is the

material movement service that initiates the

transfer of material between modules.

• Req indicates that the service is a Request.

• (...) indicates any other parameters that might be

present with the service definition and will be

service-dependent.

Definitions:

CC = Cluster Controller

CM = Cassette Module