semi合集-English.pdf - 第3586页

SEMI E139-0705 © SEMI 2005 10 7.12.1.1.3 The second part of the PDE contains the settings and executable instructions. The format of the PDEbody is not specifi ed and is allowe d to be private (that is, propri etary and …

100%1 / 7923
SEMI E139-0705 © SEMI 2005 9
execute. These are the recipes that RaP proposes to manage. RaP does not require use of or compliance with SEMI
E120. However, if SEMI E120 compliance exists, then the source EquipmentElement of much of the RaP related
data (both input and output) would be more explicitly identified.
7.7.4 From the FICS point of view, enough must be known about the recipe so that it can select the correct one for
each situation (combination of machine, substrate, process step, etc.).
7.8 Creation and Editing of Recipes
7.8.1 RaP considers creation and editing of recipes to be an independent concept. This means that the editing
capability can reside on the equipment, within the factory system, as a separate entity independent of both, or in
combinations of all of these. There are advantages and disadvantages to each and these will change over time.
Therefore, RaP makes no requirement on where the PDEeditor must reside.
7.9 Tracking and Storage of Recipes
7.9.1 Storage of at least some recipes on the equipment is necessary to support processing. Storage of recipes at the
PDEeditor is also necessary, for example, to support creation of multi-part recipes. Most factories would also be
expected to store a copy of most recipes for safekeeping. So all participants in recipe management might reasonably
be expected to store at least some recipes.
7.9.2 RaP also makes available characteristics of the recipes that support tracking and validation (id, checksum,
creation date, etc.).
7.10 Communication Overview
7.10.1 RaP is focused on the communications among the three “RaPnodes” defined above: FICSnode,
EquipmentNode, and EditorNode. There are three types of functions that can be performed via a RaP interface:
Transfer PDEs — request PDEs from or send PDEs to a node.
Manage PDEs — obtain information about the PDEs on a node and delete them when desired.
Verify — determine which PDEs are needed for a job and check that all are present and well-formed.
7.10.2 These three categories represent the eight services defined by RaP. Detailed definition of the communication
services is provided in ¶8.4. That section also defines which RaPnodes must support which of these functions. ¶8.5
defines additional requirements on the RaPnodes.
7.11 Key Recipe Concepts
7.11.1 In order to fulfill its purpose, RaP must provide more than simple recipe transfer services. This section
describes key concepts used in this specification to enhance the basic functions above to yield a robust “Recipe and
Parameter Management” capability.
7.12 ProcessDefinitionElement
7.12.1 A recipe can be a single component or it can be made up of multiple components. The components of a
recipe are called ProcessDefinitionElements or PDEs. The PDE is the central artifact of RaP. This section
describes the PDE.
7.12.1.1 PDE –Two Parts
7.12.1.1.1 One barrier to automation of recipe handling is the opaque nature of the contents. For several reasons,
suppliers have been reluctant to allow the user (and thus the automation system) visibility to the recipe contents.
RaP addresses that problem by dividing the recipe component (or now, PDE) into two parts: documentation and
executable. This is illustrated in Figure 3.
7.12.1.1.2 The documentation part of the PDE includes the PDEheader. This part is always public and available to
the user. The PDEheader contains such information as the name, description, and author of the PDE as well as its
antecedents (PDEs upon which this one was based) and the Process Module(s) for which it is intended. More detail
about the PDEheader content can be found in ¶8.3.2.
SEMI E139-0705 © SEMI 2005 10
7.12.1.1.3 The second part of the PDE contains the settings and executable instructions. The format of the
PDEbody is not specified and is allowed to be private (that is, proprietary and opaque). Note that during job
execution, the equipment relies upon the content of the PDEbody, not the PDEheader.
PDE
• Checksum
PDEheader
<<Documentation Part>>
• Name
• Identifier
• Group ID
• Description
• Author
PDEbody
<<Executable Part>>
Content is not specified
and may be ke pt private
• Target Equipment
• Antecedents
• PDE References
• Input Parameters
• . . .
PDE
• Checksum
PDEheader
<<Documentation Part>>
• Name
• Identifier
• Group ID
• Description
• Author
PDEbody
<<Executable Part>>
Content is not specified
and may be ke pt private
• Target Equipment
• Antecedents
• PDE References
• Input Parameters
• . . .
Figure 3
PDE Contents
7.12.1.2 Assuring Identity
7.12.1.2.1 An important aspect of the PDEheader information is that it can provide assurance that this PDE is
exactly the one that the factory expects it to be. This is done primarily with two data values: uid and checksum.
The uid is a universally unique identifier that contains a uuid value as defined in the referenced ISO standard (see
¶4.2). Each time a PDE is modified, the uid of that PDE is required to be changed. Therefore, if the uid is matched,
the PDE is guaranteed to be the expected one.
7.12.1.2.2 There are checksum values provided for the PDE as an additional assurance that no changes to the PDE
have occurred. The checksum for a given item is calculated using the MD5 technique defined by the IETF (see
§10). This computed value could be compared with the previously calculated value stored within the PDE to ensure
that no changes have been made.
7.12.1.3 Separate PDEbody
7.12.1.3.1 When the PDEbody is contained within the PDE, it is of the same format
5
as the PDEheader and its
contents are typically comprehensible to the user. When the PDEbody is opaque to the user or of a format that is not
compatible with the header information, that PDEbody is stored separately from the PDE. This is illustrated in
Figure 4. In this case, the separate PDEbody has its checksum stored in the PDE.
5 The definition of the format of the PDEheader is an implementation issue and will be defined in a subordinate specification to this one.
SEMI E139-0705 © SEMI 2005 11
PDE
•Checksum
•PDEbody Checksum
PDEheader
<<Documentation Part>>
• Name
• Identifier
• Group ID
• Description
• Author
PDEbody
<<Executable Part>>
• uuid
• Target Equipment
• Antecedents
• PDE References
• Input Parameters
• …
PDE
•Checksum
•PDEbody Checksum
PDEheader
<<Documentation Part>>
• Name
• Identifier
• Group ID
• Description
• Author
PDEbody
<<Executable Part>>
• uuid
• Target Equipment
• Antecedents
• PDE References
• Input Parameters
• …
Figure 4
PDE With Separate PDEbody
7.12.1.3.2 Tracking of separate PDEbodies requires some care by the FICS, because the identity cannot be obtained
from the PDEbody itself. Thus, a method for maintaining the relationship of the PDE to its body must be employed
by the FICS.
7.12.1.3.3 The Equipment and PDEeditor can interpret the PDEbody contents, and so are able to resolve the
relationship without such careful tracking. The PDEbody must include key information, such as the uid, that
enables the equipment and the PDEeditor to make the association between PDEheader and PDEbody (see ¶8.5.4.5
).
7.12.1.4 Input Parameters
7.12.1.4.1 The PDEbody may also define input parameters that can be set at run-time. The PDEheader documents
these PDEparameters. Parameterization is discussed further in ¶7.12.3.
7.12.1.5 Reference To Other PDEs
7.12.1.5.1 The PDE may need to access other PDEs during execution (for example, a subroutine call). The
PDEheader documents these references. There are two ways to reference a PDE. The first is by a unique identifier
(uid). The uid is a reference to a specific PDE. The second way to reference is by a group identifier (gid). PDEs in
a group can be substituted for one another and so must share the same set of input parameters. This type of
reference is resolved to a specific member of the group before execution. See ¶7.12.2.5 for more on how references
are resolved.
7.12.1.6 Transition To RaP
7.12.1.6.1 The approach for defining the PDE provides a good transition path from traditional proprietary recipes.
Old style recipes can become the PDEbody when RaP is applied. Since the “PDEbody
” can be a separate entity (in
the case of proprietary content), there should be many cases where little or no modification of the original recipes
will be needed. The PDE construct, including the PDEheader, acts as a wrapper.
7.12.1.6.2 There are two areas where RaP requirements may result in changes to an existing recipe structure. The
first area is the requirement that an EquipmentNode be able to match a PDEheader with its external PDEbody. This
would be done best by inserting the uid value into the PDEbody. However, there is a “bodyChecksum” value in the
PDEheader that can be used without changing the PDEbody. This would require recalculating the checksum of the
PDEbody, however. The second area is the requirement that the user be allowed to specify which PDEparameters
exist. The PDEbody must contain information about the user-specified PDEparameters. However, in the case of an
existing recipe with no user-specified PDEparameters, no change is necessary until the user edits the PDE to add
such parameters. For example, the implementer may choose to support the old recipe format for existing recipes,
but convert all new recipes to a new format that includes PDEparameter support.