semi合集-English.pdf - 第3592页

SEMI E139-0705 © SEMI 2005 16 8.2 Recipe Object Model 8.2.1 RaP recipes c onsist of a hi erarchy of recipe com ponents. Each recipe component is a PD E . In this hierarchy, each PDE may use other PDEs in order to do its …

100%1 / 7923
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.
SEMI E139-0705 © SEMI 2005 17
8.3.1.1.2 The PDEbody may be internal to the PDE (as represented by the PDEbody class) or external (as
represented by the PDEbodyReference class). The PDEbody shall be internal to the PDE only if its format
corresponds to the same formatting rules as the PDEheader. The formatting rules are defined in one or more
subordinate specifications of this document.
8.3.1.1.3 PDEs have no state. Therefore, there are no events defined for reporting the state change of a PDE.
However, see ¶8.5.4.7 for a discussion of events relating to changes in an equipment’s recipe collection.
Table 3 PDE Class Attributes
Attribute Name Definition Access Reqd Form
checksum Checksum value of the PDE data structure. If the PDEbody is external, that
external portion is not included in the checksum calculation. The checksum
value is dependent on the PDE format. The subordinate specification that
defines the PDE format will address practical details of checksum calculation.
RO Y Checksum
Table 4 Navigable Associations for PDE
Type Description Associated Class Role Cardinality
Composition PDE contains a PDEheader. PDEheader none 1
Composition PDE contains a PDEbody (XOR’ed with composition
below - exactly one of these two associations will exist).
PDEbody none 0..1
Composition PDE contains a PDEbodyReference. PDEbodyReference none 0..1
8.3.2 PDEheader Class
8.3.2.1 The PDEheader documents the contents of the PDEbody. A PDEheader contains no executable
instructions, but simply reflects the executable instructions contained by the PDEbody as well as key context and
descriptive information.
8.3.2.2 A PDEheader shall be created by the PDEeditor each time a PDE is produced. The PDEheader and
PDEbody are a matched pair and shall not be modified independently.
8.3.2.3 The PDEheader attributes are defined in Table 5. In addition, the PDEheader is composed of a list of
AntecedentData, ReferencedPDEs, PDEparameters, and ExecutionTargets. These associations are described in
Table 5 and the associated classes are described below.
Table 5 PDEheader Class Attributes
Attribute Name Definition Access Reqd Form
uid Universally unique identifier, containing a uuid value as defined by ISO (see
¶4.2). The value of uid is not user interpretable. Any two PDEs that have the
same uid shall have identical contents. They are functionally the same PDE.
RO Y UUID
name The name is a user assigned designation for the PDE. It is not required to be
unique. The value of name should be user comprehensible. It is
recommended that the name reflect the purpose of the PDE. The
EquipmentNode and EditorNode shall place no restrictions on content of the
name attribute.
RO Y String
gid Group identifier, formatted identically to the uid attribute. PDEs with the
same gid may be substituted for one another in a recipe structure (see below).
RO Y UUID
groupName The groupName is a user assigned designation for the group. All members of
a group shall have the same groupName. However, groupName is not
required to be unique among groups (gid is the unique identifier). The value
of groupName should be user comprehensible. It is recommended that the
groupName reflect the purpose of the PDE group.
RO Y String
description User assigned text describing the PDE. RO Y String