semi合集-English.pdf - 第1641页

SEMI E38-1296 © SEMI 1995 , 1996 30 host comm unication standards t o cluster- based equipment. Belo w , each GEM capab ility will be addressed separately, followed b y a look at capabilities which GEM does not cover. Th…

SEMI E38-1296 © SEMI 1995, 199629

APPENDIX 1

APPLICATION NOTES

NOTE: This appendix was approved as a part of SEMI E38 by full letter ballot procedure.

A1-1 Factory Integration

The Cluster Tool Module Communications (CTMC)

Standard and its associated services define the

interactions of the cluster modules and the cluster

controller. The standard does not address the

communications between the cluster and an external

factory “host.” The SEMI standard which addresses the

equipment to host communications interface is SEMI

E30 (GEM).

The purpose of this application note is to discuss the

requirements and possible pitfalls of the factory host-

cluster tool interface. The bulk of the text will address

the use of the current (at this writing) version of GEM

(SEMI E30). However, some consideration will be

given to the possibility of direct access to the

components of the cluster through the cluster

communications environment.

A1-1.1 Direct Access to Cluster Modules — The

CTMC was designed to allow for interoperability

among the entities in a cluster. It is possible to add a

new entity to the cluster and share in this

interoperability. This means that a software application

that is “plugged” into the cluster communication

environment will have access to all of the cluster

modules via the standard message set. In this way, a

factory host computer can gain direct access to cluster

modules, by-passing the cluster controller.

While direct access to the cluster modules has some

advantages, intrusions into the cluster tool

communications environment can have a profound

effect on the system. Below are listed a few of the

positive benefits direct access can bring, followed by

some of the negatives of such an approach.

Positives:

• If the cluster controller does not have to act as the

intermediary in transactions between module and

host, it may be simplified.

• Direct access of the modules can be a more

efficient means of obtaining information.

• The factory host would have the flexibility to

perform scenarios which the cluster controller

suppliers had not imagined.

Negatives:

• A new, unplanned load on the cluster network may

have a negative impact on system performance. If

the delivered system’s network is highly loaded

and has been tuned for that load, added pressure on

the system may have unexpected results.

• Direct access of the cluster modules may have a

negative impact on system performance. The

cluster modules are performing the physical work

for the cluster. If they become busy answering

inquiries, it may detract from their speed of

processing. For example, a simple query, such as

temperature of chamber, may actually result in

messaging to the sensor itself along the same real-

time communication path used to open and close

valves, ect.

• System integrity of the cluster tool may be at risk if

an external entity (e.g., Factory Host) takes even

minor control actions. A changed equipment

constant may put the cluster controller out of synch

with its module. An external command to perform

an action may directly conflict with the cluster’s

current actions.

• The CTMC defines no access security to prevent

undesirable actions on the part of external entities.

If there is to be this sort of direct communication with

cluster modules, the implementer should exercise

extreme caution in the design of the add-on application.

It is recommended that no active control be attempted

and that no changes to the system configuration be

attempted (e.g., do not set attributes). If data is to be

accessed, it is best done by asynchronous event based

reporting, rather than by polling. Above all, it is

recommended that any plans to access the cluster

through the cluster communication environment be

discussed thoroughly with the system supplier.

A1-1.2 GEM Control of a Cluster Tool — This section

discusses the interactions between a cluster tool and

factory host. The basis for that communication is

assumed to be SEMI E30, the Generic Equipment

Model.

GEM was designed relative to the prevalent class of

equipment at that time: proprietary, single supplier, and

limited to a single process run at a time. The advent of

multi-chamber processing equipment and later of multi-

supplier cluster tools has changed the general

requirements set for the factory-equipment interface. In

the future, GEM may evolve to meet these new

requirements. Regardless, the point of this application

note is to explore how best to apply the existing factory

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.