semi合集-English.pdf - 第1847页

SEMI E42-0704 © SEMI 1995, 2004 116 RELATED INFORMATION 1 NOTE: This related information is not an official part of SEMI E42 and i s not intended to m odify or superse de the official standard. Rather, these notes are au…

SEMI E42-0704 © SEMI 1995, 2004 115

which is placed in the Parameters attribute of the recipe

when it is verified; (2) Permitting the actual value to be

supplied externally by a parent recipe, or at the time the

recipe is selected for execution by the supervisor or the

operator.

verification area — Optional temporary storage

provided for unverified downloaded recipes.

verify — The operation of (1) ensuring that a recipe is

syntactically correct, and (2) identifying variable

parameters and external references.

version — A text string that is part of a recipe's

identifier.

version number — A version consisting only of the

digits “0” through “9” and one decimal point character

“.” that can be translated to a pure number. Only whole

numbers (with no decimal point) and numbers with a

decimal point that do not begin or end with a “0” may

be used.

whitespace — In ASCII, the space (20

), tab (9

carriage return (0D

), and form feed (0C

) characters.

write-protect — See protect.

NOTICE: These standards do not purport to address

safety issues, if any, associated with their use. It is the

responsibility of the user of these standards to establish

appropriate safety and health practices and determine

the applicability of regulatory limitations prior to use.

SEMI makes no warranties or representations as to the

suitability of the standards set forth herein for any

particular application. The determination of the

suitability of the standard is solely the responsibility of

the user. Users are cautioned to refer to manufacturer's

instructions, product labels, product data sheets, and

other relevant literature respecting any materials

mentioned herein. These standards are subject to

change without notice.

The user’s attention is called to the possibility that

compliance with this standard may require use of

copyrighted material or of an invention covered by

patent rights. By publication of this standard, SEMI

takes no position respecting the validity of any patent

rights or copyrights asserted in connection with any

item mentioned in this standard. Users of this standard

are expressly advised that determination of any such

patent rights or copyrights, and the risk of infringement

of such rights, are entirely their own responsibility.

SEMI E42-0704 © SEMI 1995, 2004 116

RELATED INFORMATION 1

NOTE: This related information is not an official part of SEMI E42 and is not intended to modify or supersede the

official standard. Rather, these notes are auxiliary information provided as background or examples of possible

application and are included as reference material. The standard should be referred to in all cases. SEMI makes no

warranties or representations as to the suitability of the material set forth herein for any particular application. The

determination of the suitability of the material is solely the responsibility of the user.

R1-1 RMS Standardized Objects

The standardized objects defined by RMS are shown in Table R1-1.

Table R1-1 Standardized Objects

Object Type ObjType Section Reference

Managed Recipe MRcp 3.4.2.1

Agent-Specific Dataset MRcpASDS 3.4.2.2

Execution Recipe ERcp 3.5.4

Recipe Namespace RNS 4.6

Recipe Namespace Manager RNS_Mgr 4.6

Recipe Executor RcpExec 6.8

Agent Agent 7.3

R1-2 RMS Requirements/Concepts Map

Table R1-2 provides the specific RMS concepts that address each of the requirements from Table 2.1.

Table R1-2 RMS Requirements/Concepts Map

Requirement Concept

Uniquely store, identify, and select recipes in a system.

Share recipes among different agents.

Synchronize the change of shared recipes among agents.

Share recipes among different installations of the same type of equipment by

adjusting individual differences.

Namespace

Ability to execute recipes with or without a communication link.

Ability to change recipes managed by another agent when the communication

link has failed or before it is established.

Default Namespace

Formal differentiation of, and recognition of, recipes of different types. Recipe Class

Allow a recipe name to retain its base identity across a series of modifications. Version Number

Allow shared recipes to be adjusted for individual pieces of equipment.

Allow a recipe’s parameters to be adjusted within specified limits without

requiring the recipe body to be changed.

Support feedback/feed forward control.

Variable Parameters

Ensure the recipe is syntactically correct. Verification

Manage the approval level of specific recipes with respect to process

development and production-worthiness.

Approval

Allow management of equipment qualified for specific recipes. Certification

Change the recipe while it is running. Protection of execution area from inadvertent

change

SEMI E42-0704 © SEMI 1995, 2004 117

R1-3 Background

The material in this section provides a context for the

Recipe Management Standard and is intended for

background information only.

In a complex environment, equipment and host become

relative terms indicating roles of two independent

agents with respect to each other. In general, both

equipment and host may provide services to one

another, and some services may be provided by both. In

certain cases, one may provide services to its partner

that the other does not. With respect to recipes,

equipment refers to the recipe’s executor, whereas host

represents a supervisory agent who may delegate

recipes which will be executed by the equipment.

For clusters, cells, and local-area stations, where a mid-

level controller communicates both to lower-level

components and to a higher level factory system, that

controller may alternately take the role of host to its

components and of equipment to the factory system.

Where role is significant, the terms equipment and host

are used in this section to indicate the relationship of

the two agents to one another.

R1-3.1 Traceability — A main management objective

in both a Development Fab and a Production Fab is

traceability of manufacturing conditions to the final

device characteristics. This traceability is required in a

Development Fab to support the analysis and

characterization of the process under development.

Certain customers of a Production Fab require this

traceability in order to do business. Even without such a

customer requirement, traceability is important for

process control and postmortem analysis of unexpected

device characteristics.

The recipe is the primary specification of

manufacturing conditions to the equipment; therefore,

the management of recipes is critical to this traceability.

R1-3.2 Recipe Life Cycle — The lifetime of a recipe in

a Fab typically has several phases, as illustrated in

Figure R1-1. While being developed, it may contain

errors, or it may not produce the desired results. The

recipe may be edited several times during its initial

development. At some point, the recipe enters the test

phase, where it will be executed and its results

evaluated. A check for syntax correctness occurs at or

before the time the equipment prepares it for execution.

Still further changes may be made to fine-tune the

process to achieve a particular result. During this

process, it is still desirable to be able to protect it from

inadvertent change or deletion. Finally, the recipe is

ready for production and goes through a series of

signoffs which constitutes a formal authorization

procedure. In many factories, only recipes which have

been approved as production-worthy may be used in

production runs.

Figure R1-1

Typical Recipe Life Cycle

Also, because results may vary between different

installations of equipment, an additional level of

authorization may be required that certifies individual

equipment for a given approved recipe.

A factory change control system must accommodate

different levels of protection for recipes in different

phases of their life cycle. To accomplish this,

equipment must recognize and support the different

requirements for each phase.

R1-3.3 Recipe Editing — Traditionally, recipes are

developed on the equipment that runs them. Besides

requiring time on the target machine (a potentially

scarce and expensive resource), this requires the person

defining the recipe to be inside a clean area. A potential

solution is for equipment manufacturers to provide

versions of their dedicated recipe editors that can be

integrated into the factory manufacturing systems.

Aside from the difficulty of the equipment

manufacturer supporting the variety of platforms

currently in use internationally, even in a distributed

factory environment, a proliferation of different

dedicated recipe editors required for the different types

of equipment is not considered a good solution.

A better solution is to permit editing external to the

cleanroom and then to transmit the completed recipe to

the equipment for verification. This can be achieved by

providing a text

form of the equipment manufacturer’s

recipe language which can be created and modified

with any standard text editor. This may not be possible

with some types of recipes (e.g., pattern recognition