semi合集-English.pdf - 第1848页
SEMI E42-0704 © SEMI 1995, 2004 117 R1-3 Background The material in this section provides a contex t for the Recipe Managem ent Standard and is int ended for background info rmation only. In a compl ex enviro nment, equi…
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
SEMI E42-0704 © SEMI 1995, 2004 118
programs for vision systems), but this restriction may
be removed when the technology advances.
Editing on the equipment may still be desirable,
particularly in a Development Fab. When the equipment
permits a recipe to be changed, the equipment must
provide reporting mechanisms that inform the host of
changes and allow the host’s change control system to
operate.
R1-3.4 Recipe Sharing — A Fab may have several
installation of the same type of equipment (equipment
with the same functionality and the same recipe
language). Therefore, where possible, the same recipe
should be able to be shared between different
equipment of this same type.
R1-3.5 Protection and Process Control — The primary
goal of process control is to ensure that the final result
of the manufacturing process does not change over
time. This may be accomplished by both feedback and
feedforward methods. These methods modify the
settings used in the process. This requires two
capabilities that seem to be in conflict:
• The definition of the process settings (the recipe)
should not change.
• The process settings should change to counter the
drift inherent in real processes.
The first capability is particularly important in a
Production Fab. Most Fab policies prohibit processes
from changing after they have been approved for
production. This is easy to build into a change control
system on the host. However, if the equipment allows
local editing, then it must also enforce this policy.
Wholesale changes in a recipe are never necessary for
the second purpose. Usually only a few parameter
values are modified in small increments to effect
control of the process. A well-defined process specifies
the parameters that vary and their range of variation.
For any given recipe, it must be possible for the host to
specify different values of such parameters for each
piece of equipment so that the recipe may be “tuned”
for that equipment to produce uniform results. In
addition, the process control agent, on the equipment or
the host, may need the ability to calculate the parameter
value changes for each run and to inform the equipment
of the new values. Mechanisms are provided to support
such interactions.
R1-3.6 Recipe Selection — Typical operation of
equipment requires an operator or the host to initially
select the recipe to be run. Recipe selection may be
specified implicitly within the definition of a higher
order “process job”. In either case, the specification of a
recipe is accomplished by referring to its recipe
identifier (i.e., the identifier used by the change control
system) and, where needed to resolve ambiguity, its
location. Once selected, a recipe is initiated by an
appropriate start command, which may be explicitly
given by the operator or host or implicitly given by the
equipment when executing a higher order process job.
Repeated runs of the same recipe may be accomplished
via subsequent start commands without the necessity of
formal recipe re-selection.
R1-4 Example of a Factory Implementation of Approval Levels
A factory might implement different levels of approval by regulating the following levels of recipe approval on the
equipment:
Approval Level
FACTORY POLICY
Level 0 “Unapproved”
Level 1 “In Test”
Level 2 “Non-Production”
Level 3 “Ready for Release”
Level 4 “Released for Production”
with
RecipeReadOnlyLevel = 2 Level 2 = read-only
R1-5 Examples of Variable Parameters
The recipe body may have statements that allow parameters to be changed within fixed limits. For example, recipe
BAKE;2.3 may contain statements such as:
Parameter BakeTime of TIME default = 200 seconds