semi合集-English.pdf - 第3594页

SEMI E139-0705 © SEMI 2005 18 Attribute Name Definition Access Reqd Form type Supplier assigned string used to differen tiate the kinds of PDEs used on the equipment. For exam ple, the sup plier might designate types suc…

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.

8.3.3.3 The user may limit the number of AntecedentData instances by setting the maxAntecedents attribute of the

PDE. This leaves only the most recent entries in each branch of AntecedentData. See Table 7 for more on

maxAntecedents.

Table 7 AntecedentData Class Attributes

Attribute Name Definition Access Reqd Form

uid Universally unique identifier of a PDE upon which the current PDE is based. RO Y UUID

name Value of the name attribute of the PDE identified by the uid above. RO Y String

gid Value of the gid attribute of the PDE identified by the uid above. RO Y UUID

groupName Value of the groupName attribute of the PDE identified by the uid above. RO Y String

description Value of the description attribute of the PDE identified by the uid above. RO Y String

author Value of the author attribute of the PDE identified by the uid above. RO Y String

createDate Value of the createDate attribute of the PDE identified by the uid above. RO Y Time

createNode Value of the createNode attribute of the PDE identified by the uid above. RO Y String

Table 8 Navigable Associations for AntecedentData

Type Description Associated Class Role Cardinality

Composition AntecedentData may contain AntecedentData. This represents

the sequence of precursor PDEs backwards through time.

AntecedentData none 0..*

8.3.4 ReferencedPDE Class

8.3.4.1 This class contains a reference to a PDE that is needed by the current PDE to complete its task. At any

point in the structure of a recipe, the set of ReferencedPDEs provides the identities of the PDEs at the next lower

level.

8.3.4.2 The value of the id attribute can be either a uid or gid. Since all UUID type values are universally unique,

there is no conflict. If the id contains a uid value, the reference is explicit and no further work is needed. If the id

contains a gid value, then it will be resolved to a uid at a later time (see ¶8.5.1.3 for more detail).

8.3.4.3 A PDE shall ensure that the PDEparameters of all of its ReferencedPDEs are satisfied, by either providing a

value or allowing the default to be used (if one exists).

Table 9 ReferencedPDE Class Attributes

Attribute Name Definition Access Reqd Form

id Identifier of the PDE being referenced. This attribute may contain the

value of the uid or of the gid of an appropriate PDE.

RO Y UUID

8.3.5 ExecutionTarget Class

8.3.5.1 ExecutionTarget describes the Process Module(s) on which this PDE can be executed. The supplier, make,

model, and recipeTypes attributes define the type of Process Module that can execute this PDE. Based on the

definition of these attributes, an ExecutionTarget may represent a general set of acceptable Process Modules. If the

identifier attribute is also be specified, the ExecutionTarget is limited to one specific unit. The PDEeditor shall

ensure that the ExecutionTarget definition shall describe only equipment that are able to execute this PDE.

8.3.5.2 A PDE’s ExecutionTarget instances should correspond to its scope of execution. A Master PDE’s scope

would typically be the equipment.

8.3.5.3 An equipment can contain multiple Process Modules that match ExecutionTarget definitions for a PDE. In

this case, the equipment, with possible guidance from the recipe, shall select which to use during processing.