semi合集-English.pdf - 第3591页

SEMI E139-0705 © SEMI 2005 15 7.12.4 TransferContainer 7.12.4.1 ¶7.10 m entions the trans fer of PDEs . RaP pr ovides for the defini tion of a process activi ty to span multipl e, inter-related PDEs . To pro mote efficie…

100%1 / 7923
SEMI E139-0705 © SEMI 2005 14
Variable
Parameter
Variable
Parameter
PDE
PDE
PDE
Parameter
PDE
Parameter
Process
Module
PDE
“Master”
PDE
Coordinates
Targeted For
PDE
Parameter
Module
Parameter
Input For
Input For
Input For
PDE
Parameter
Variable
Parameter
Variable
Parameter
Process
Job
Executes
Input For
Variable
Parameter
S
et
s
S
et
s
S
et
s
Variable
Parameter
Variable
Parameter
PDE
PDE
PDE
Parameter
PDE
Parameter
Process
Module
PDE
“Master”
PDE
Coordinates
Targeted For
PDE
Parameter
Module
Parameter
Input For
Input For
Input For
PDE
Parameter
Variable
Parameter
Variable
Parameter
Process
Job
Executes
Input For
Variable
Parameter
S
et
s
S
et
s
S
et
s
S
et
s
S
et
s
Figure 6
Parameter Flow Illustration
7.12.3.2 RaP assumes that recipes are executed as part of a larger job specification. When the “Process Job” is to
be executed, settings can be passed to the job to complete its specification. In RaP, these settings are called Variable
Parameters. Figure 6 shows Variable Parameters passed to the Process Job.
7.12.3.3 The Process Job references the Master PDE as the process recipe. During execution of the Process Job,
the equipment passes Variable Parameter values to the Master PDE to satisfy its PDEparameters.
7.12.3.4 The Master PDE and each successive level of PDEs coordinate the activity of the PDEs at the next lower
level. Each PDE is responsible for passing values to its referenced PDEs to satisfy their PDEparameters.
7.12.3.5 Each PDE can also directly set “Module Parameters”, the settings that affect the Process Module (or other
equipment components). Each Process Module offers a fixed set of these input parameters that can be set from
within a recipe. Note that Module Parameters are not formally defined by RaP. They are used to represent internal
equipment settings that recipes need to manipulate.
7.12.3.6 For a particular PDE, an incoming PDEparameter value may affect an outgoing setting of another PDEs
PDEparameter or of a Module Parameter. This affect may be direct, where the incoming value is used as the
outgoing value, or it may be indirect, where some sort of transformation is done to the incoming setting to determine
the outgoing values. An example of an indirect affect is a time setting that is consumed within the PDE and is used
to determine when a particular Module Parameter is to be set.
7.12.3.7 Notice that a PDE can set Module Parameters to different values during processing according to need. For
example, a process chamber might have a “ChamberTemperatureSetpoint” Module Parameter. A PDE might
require that the value for this be 450°C for the first stage of the process and 500°C for the second stage. The PDE
could set these values directly at the proper time. However, an alternative would be to define two PDEparameters
for this purpose: FirstStageTemp and SecondStageTemp. Each would map to ChamberTemperatureSetpoint and
their default values could be set to the corresponding values. Then, when the appropriate first stage temperature is
determined to be 430°C, the change can be made through a parameter setting at runtime without changing the PDE.
In this way, multiple PDEparameters might map to the same Module Parameter.
SEMI E139-0705 © SEMI 2005 15
7.12.4 TransferContainer
7.12.4.1 ¶7.10 mentions the transfer of PDEs. RaP provides for the definition of a process activity to span multiple,
inter-related PDEs. To promote efficiency of messaging and organization of these PDEs, RaP defines the
TransferContainer. A TransferContainer bundles together multiple PDEs for transfer.
7.12.4.2 A TransferContainer contains PDEs, PDEbodies, and a Manifest. It is convenient to conceptualize the
TransferContainer as an archive file (for instance, a compressed “zip” file for efficient transfer) and the PDE and
PDEbodies as files contained within.
7.12.4.3 There is no requirement that the PDEs contained in a TransferContainer be related in any way. Nor is
there any requirement that all PDEs required for a particular equipment activity to be transferred together.
However, RaP does insist that an external PDEbody always be accompanied by its PDE (and thus, its PDEheader).
7.12.4.4 The Manifest lists which PDEs are included in the TransferContainer and associates each PDE with its
external PDEbody (if one exists). The Manifest can also specify a storage location on the equipment for each recipe
(for example a directory).
7.12.4.5 More detail is provided in ¶8.4.2.13.
7.13 Realizing the Purpose
7.13.1 The purpose of RaP was discussed in §1. In that section, six primary elements of the purpose were provided.
This section will review these six elements and show how each is satisfied by the concepts defined in §7.
On-tool & Off-tool Recipe Management — RaP provides the ability to uniquely identify each PDE. This is
done independently of the versioning systems that may be used by the host or equipment recipe managers. On-
tool management information is embedded in the PDE header (version, antecedent, etc.), but the host may
choose to ignore this information and follow its own management procedures. Few requirements are placed on
the host or equipment with regard to how management of PDEs is to be done.
Recipe Integrity — To guarantee integrity of the recipes, it must be possible to uniquely identify each PDE and
recognize that any change makes it a different PDE. The unique identification requirement is satisfied by the
definition of a unique identifier (uid) containing a uuid value and by the requirement to change the uid with any
change to the PDE. Checksums provide added certainty that no change was made.
Process Integrity — RaP addresses this requirement by making all Module Parameters available for setting by a
PDE, either directly or as input parameters to be supplied at execution time. RaP cannot guarantee that all
possible parameters have been made available to the PDEs. This is left to the supplier and user communities to
ensure.
Adjustable Parameter Definition — RaP provides a flexible system for defining parameters for process jobs in a
way that is compatible with SEMI standards (for example SEMI E40). See ¶7.12.3.
On-tool & Off-tool Recipe Creation & Editing — RaP requires that recipe creation and editing capability exist.
It defines the interfaces necessary to standardize communication with an off-tool editor. RaP does not require
an off-tool editor.
Information Accessibility — The PDEheader contains a large amount of user-accessible information about
individual PDEs and how they relate to one another.
8 Requirements
8.1 Requirements Overview
8.1.1 This section contains all of the requirements specified by RaP. This is divided into three parts.
The first is the Recipe Object Model, which describes the data content of the recipe components.
The second part is RaP Services, which defines the communications between participants in recipe
management.
The third part is RaPnode Requirements and Clarifications, which defines the responsibilities of each recipe
management participant.
SEMI E139-0705 © SEMI 2005 16
8.2 Recipe Object Model
8.2.1 RaP recipes consist of a hierarchy of recipe components. Each recipe component is a PDE. In this hierarchy,
each PDE may use other PDEs in order to do its job. Note that a PDE may appear multiple times in the hierarchy.
Each appearance represents a different use of this PDE.
8.2.2 At the apex of the hierarchy is a single PDE that represents the entire recipe . This topmost PDE is referred to
as the “Master PDE”. The only additional RaP requirement on a PDE in order to serve as a Master PDE is that it
shall have its “executable” attribute set to “True” (see Table 5).
8.2.3 The Recipe Object Model specifies the requirements that RaP places on the content of PDEs. These PDEs are
the subject of the RaP Services (see ¶8.4). Certain information about PDEs can be accessed directly by PDE
services (for example, see getPDEdirectory()). That information is also defined in the Recipe Object Model.
8.2.4 The Recipe Object Model specifically applies to the form of the PDEs during transfer. RaP does not place
any requirements on the stored form of any PDE so long as the meaning of the PDE is not lost and the exact transfer
form can be reconstructed for later transfer.
8.3 PDE Class Diagram
8.3.1 The PDE Class Diagram (Figure 7) represents the information contained in the PDE. In addition to the
executable instructions, the PDE provides a public description of itself. This provides accessibility to the user of
key information about the PDE, while allowing the equipment supplier to protect the integrity and any proprietary
value of the actual processing instructions.
Re fe r e nce dPDE
id
0..*
AntecedentData
uid
name
gid
groupName
description
author
createDate
createNode
0..*
PDEhe ader
uid
name
gid
groupName
description
type
executable
maxAntecedents
createDate
createNode
author
userInfo
supplierInfo
PDEparam eter
name
description
units
relatedParameters
defaultValue
inputBoundaryType
inputBounds
ExecutionTarget
identifier
supplier
make
model
recipeTypes
0..* 0..*
0..*
PDE
checksum
PDEbody
0..1
1
PDEbodyReference
specification
bodyChecksum
0..1
xor
Figure 7
PDE Class Diagram
8.3.1.1 PDE Class
8.3.1.1.1 The PDE includes a PDEheader that describes the PDE and a PDEbody that contains the executable
instructions. The PDEheader stores key information about the PDE, its purpose, its history, etc.