semi合集-English.pdf - 第3593页

SEMI E139-0705 © SEMI 2005 17 8.3.1.1. 2 The PDEbody m ay be internal to the PDE (as represented by the PDEbod y class) or external (as represented by t h e PDEbodyReference clas s). The PDEbody shall be internal to the …

100%1 / 7923
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
SEMI E139-0705 © SEMI 2005 18
Attribute Name Definition Access Reqd Form
type Supplier assigned string used to differentiate the kinds of PDEs used on the
equipment. For example, the supplier might designate types such as “flow”,
“unit”, “image”, “inline-metrology”, etc.
RO N String
executable When = True, indicates that the PDE can serve as a Master PDE. RO Y Boolean
maxAntecedents The maximum number of AntecedentData records that may be kept in this
PDE. In the case of branching (where multiple antecedents for a PDE
existed), maxAntecedents is the maximum number of AntecedentData records
in any one path backwards through the antecedents. See the definition of the
AntecedentData class in ¶8.3.3. If zero, no Antecedents are kept.
RO Y Integer
createDate Date/time the PDE was created. RO Y Time
createNode Identifier (nodeID) of the RaPnode where the PDE was created. If the
creation location was not associated with a RaPnode, createNode shall contain
an identifier that uniquely identifies the creating entity within the factory.
RO Y String
author Name of the creator of the PDE. Note that a PDE can be “created”, but not
“modified”, since any modification results in a new PDE.
RO Y String
userInfo A list of strings that contain text entered by the user. However, neither the
Equipment nor PDEeditor are required to interpret or react to this information.
RO N list of String
supplierInfo A list of strings that contain text defined by the supplier. The supplierInfo
strings should provide information to the user that is not included in the
standard attributes.
RO N list of String
8.3.2.4 A gid is used to identify PDEs that are substitutable for one another. In addition to sharing the same
groupName and gid, the following shall be true for all PDEs in the same group:
They shall have the same set of PDEparameters.
The existence of PDEparameter default values shall be the same (the actual default values may differ).
Table 6 Navigable Associations for PDEheader
Type Description Associated Class Role Cardinality
Composition PDEheader may contain instances of AntecedentData to
document the predecessors of this PDE.
AntecedentData none 0..*
Composition PDEheader may contain references to other PDEs. ReferencedPDE none 0..*
Composition PDEheader may define PDEparameters to accept externally
supplied values to a PDE during run-time.
PDEparameter none 0..*
Composition PDEheader contains instances of ExecutionTarget that describe
the equipment or module that are permitted to execute this PDE.
If no ExecutionTargets are associated with the PDEheader, then
no restriction exists. The equipment implementation may restrict
the cardinality of this association to be at least one (that is, 1..*).
ExecutionTarget none 0..*
8.3.2.5 Multiple ExecutionTarget objects are defined when multiple sets of criteria are acceptable. For example,
two similar models of an equipment might be able to run the same recipe.
8.3.3 AntecedentData Class
8.3.3.1 The AntecedentData class documents the predecessors of the current PDE. When a PDE is created, if a
PDE is used as the basis for the new one, the older PDE’s relevant data is copied into the first AntecedentData
instance. Then the older PDEs AntecedentData is appended to that of the new PDE. This provides a
chronologically ordered sequence of AntecedentData instances. Since the antecedent PDEs may not be available at
a later time, some of their attributes are included in the AntecedentData class.
8.3.3.2 Note that portions of multiple PDEs may be used to create the new one. AntecedentData sequences may
branch as they move back in time.