semi合集-English.pdf - 第1626页

SEMI E38-1296 © SEMI 1995 , 1996 15 as required. Collection events may initiate and terminate the tracing in order to link reporting to significant con ditions, such as process ing. The trace data is collected at a frequ…

SEMI E38-1296 © SEMI 1995, 1996 14

Error exception conditions may have associated

recovery actions which can be performed by the module

resource to attempt to recover from the abnormal

situation. Alarm exception conditions cannot, by

definition, be resolved using recovery actions.

A list of possible recovery actions is included in a

posted error report. The decision authority can request

one of the offered recovery actions to resolve the error

condition. The selected recovery action is performed by

the appropriate module resource and may result in

clearing the error condition.

This model is used to establish the Exception

Management definition.

7.1.6 Recipe Management Model — Recipe

management in a module varies with the requirements

of the application. Simple modules do not provide local

recipe editing and don’t require management of

multiple logical domains (namespaces) and local recipe

version control.

Figure 11 shows the full recipe management model for

a sophisticated module.

Figure 11

Recipe Management Information Model

Process recipes specify the actual parameters of the

processing to be achieved. The module processing

resource identifies, through the process job, the

required recipe(s) to be loaded by the recipe executor in

order to process a particular material.

The recipe executor accesses and selects recipes for

execution. It uploads and downloads recipes from the

cluster controller and is capable of verifying that a

recipe is syntactically correct. The recipe executor also

provides for a service-user to select a recipe to be

loaded into the recipe execution area. The recipe is

made up of a recipe body and may have headers if the

module supports recipe namespace management.

The module accesses recipe namespaces where

requested by service-users. A module which does not

provide local editing and linking of recipes does not

need recipe namespace management. Recipe namespace

management requires management of recipe generic

and agent (module) specific headers. For example, a

process module could manage a recipe namespace

containing its process and service recipes.

This model is used to establish the Recipe Management

services requirements for cluster tool modules.

7.1.7 Event Reporting Model

Figure 12

Event Reporting Information Model

Event reporting provides a dynamic and flexible means

by which a service-user can receive notification of

events and data relating to module resources.

The services-user can define and enable two types of

reporting, event reporting and trace reporting. Both may

convey data, the values of identified variables at the

data collection time. The variable identifiers required to

be reported are specified in the data report definition.

In event reporting, data reports are linked to event

report definitions associated with each collection event

type. On occurrence of the collection event, an event

report message is generated according to the event

report definition and the linked data report definitions.

Reporting may be enabled and disabled for each

collection event type. Data reports and links may be

predefined or specified dynamically by the service user.

Trace reporting is time-based data reporting. Trace

reporting is specified by the service-user dynamically

SEMI E38-1296 © SEMI 1995, 199615

as required. Collection events may initiate and

terminate the tracing in order to link reporting to

significant conditions, such as processing. The trace

data is collected at a frequency specified by the service-

user. Trace reports are generated according to the trace

report definition and the associated data report

definition.

Through associating the event report and trace report

definition with the service-user, the model provides for

the association of multiple service-users to a single

service-provider. This allows for event reporting

between modules where needed as well as the ability

for direct connection of a data acquisition entity

independent of the cluster controller.

7.2 Cluster Tool Module Message Flow — The

appropriate objects in the information models in the

previous section are grouped in the cluster tool module

types. The communications with the essential objects

are shown in the message flow diagrams in this section.

The diagrams show message flow between entities

within an agent (in this case a module) and those

outside the agent. Entities are rectangular boxes, and

the agent is a rounded box. As emphasis is on the

module and its services, only one agent is shown on

each diagram. Outside entities in the cluster tool

module communications domain appear within an agent

on another diagram. The messaging is shown by arrows

in each direction, with a brief label indicating the

services requested or provided.

The communications are shown for the primary control

of the process module (Figure 13), cassette module

(Figure 14), and transport module (Figure 15). Note that

the transport module transfer resource communicates

with multiple process and cassette module intratool port

resources.

Figure 13

Process Module Primary Control Message Flow

Figure 14

Cassette Module Primary Control Message Flow

Figure 15

Transport Module Primary Control Message Flow

Figure 16

Module Exception Message Flow

Figure 17

Module Recipe Message Flow

Figure 18

Module Event Reporting Message Flow

The communications for support functionality are

shown for any module, as the services are common to

all module types. The support functionality modeled

includes exception handling (Figure 16), recipe

management (Figure 17), and event reporting (Figure

18). A typical decision authority or service-user is the

cluster controller.

7.3 Cluster Tool Behavioral Model — The process

material is the fundamentally important object in a

cluster tool and its lifecycle is the key component to

establishing cohesiveness in the communication and

controls standards.

The finite state model in Figure 19 presents the high-

level behavior of a single material within the domain of

the cluster tool. Bold transitions trace the normal

lifecycle of the material and are described in the

transition table, Table 1. Other transitions occur in

exception situations and are not detailed here. The

transition table actions indicate the primary control

operations which are requested of the modules by the

cluster controller.