semi合集-English.pdf - 第3597页

SEMI E139-0705 © SEMI 2005 21 Attribute Name Definition Access Reqd Form inputBounds A sequence of values that represent limitat ions to acceptable set tings for this Variable Parameter. If inputBoundaryType is “List”, t…

100%1 / 7923
SEMI E139-0705 © SEMI 2005 20
Table 10 ExecutionTarget Class Attributes
Attribute Name Definition Access Reqd Form
identifier Unique identifier of a specific Process Module on which this PDE can be
executed. If the identifier attribute is omitted, then any equipment that matches
the other attributes can execute this PDE.
RO N String
supplier Name of the equipment supplier. RO Y String
make Classification of equipment provided by the equipment supplier. It could
represent a product line, a division of the company or any other useful
classification of equipment.
RO Y String
model Finer grained classification of equipment provided by the equipment supplier. It
could represent a tool configuration targeted at some particular wafer process or
any other useful classification of equipment.
RO Y String
recipeTypes This is a classification field that allows identification of recipe compatibility
across multiple pieces of equipment. The supplier should define the recipeType
values that correspond to each Process Module.
Target equipment that support the same recipeType shall be capable of executing
a PDE of that type without fault.
While the recipeTypes attribute is not required by RaP, an Equipment may declare
it to be required and enforce the requirement in the PDEeditor.
RO N list of
String
8.3.6 PDEparameter Class
8.3.6.1 PDEparameters are inputs to a PDE that help determine how it will perform its task. PDEparameter input
values are supplied by the next higher level of the recipe hierarchy. For the Master PDE, they are supplied by the
equipment itself (as it executes the job/recipe). For all other PDEs, the PDEparameter values shall be supplied by
the referencing PDE.
8.3.6.2 The group of PDEs that make up a recipe are responsible for satisfying all the settings (or Module
Parameters) and any other conditions required to perform the defined activity. These Module Parameters can be set
by PDEs at any level in the hierarchy. The value of a PDEparameter may affect the eventual value of one or more
Module Parameters. The PDE may set the Module Parameters directly or it may set a PDEparameter that will
affect the value of a Module Parameter. In either case, the affected Module Parameters are considered
relatedParameters.
8.3.6.3 A PDE may set a Module Parameter to different values at different times during execution. In this case,
there may be multiple input PDEparameters that affect the same Module Parameter.
Table 11 PDEparameter Class Attributes
Attribute Name Definition Access Reqd Form
name Identifies the PDEparameter. It must be unique within the list of
PDEparameters of this PDE.
RO Y String
description Text description of the PDEparameter, its intended usage, and the
expected effect its settings will have on the activity.
RO Y String
units The units of the PDEparameter value to be supplied. RO Y String
relatedParameters The names of the Module Parameters affected by the setting of this
PDEparameter (if any).
RO N list of String
defaultValue Value to be used for this PDEparameter during execution if no external
input is provided.
RO N Any
inputBoundaryType Specifies the type of inputBounds defined for this PDEparameter.
Possible types are “List” and “Range”. If inputBounds are present, this
attribute shall also be included.
RO N Enumeration
SEMI E139-0705 © SEMI 2005 21
Attribute Name Definition Access Reqd Form
inputBounds A sequence of values that represent limitations to acceptable settings for
this Variable Parameter. If inputBoundaryType is “List”, this attribute
contains a set of discrete values that are acceptable for input. If the
inputBoundaryType is “Range”, then two values are included that define
the acceptable range of values. In this case, the first value is the lower
bound and the second is the upper bound. The acceptable range is
inclusive of the inputBounds values.
RO N list of Any –
matches
format of
defaultValue
8.3.6.4 The name of the PDEparameter shall be unique within the scope of the PDE. Also, the name of the Module
Parameters shall be unique within the scope of a Process Module.
8.3.6.5 In the case where a PDEparameter maps directly to another (lower level) PDEparameter, the inputBounds
defined shall be the same or more restrictive than those for the corresponding lower level PDEparameter. If no
inputBounds are defined, then those for the corresponding lower level PDEparameter shall be used (if any are
defined).
8.3.6.6 This specification does not define how or when the inputBounds are enforced. This is an issue of recipe
execution and is out of scope for this specification.
8.3.7 PDEbody Class
8.3.7.1 The PDEbody contains settings and/or executable instructions required by the equipment to perform a run.
It may be internal to the PDE (represented as PDEbody class) or external to the PDE (represented as
PDEbodyReference). This section defines the former.
8.3.7.2 The PDEbody class is used when the content of the PDE instructions is visible to the user. No attributes or
associations are defined for the PDEbody. The implementer is expected to create a subclass of PDEbody that
represents the content of their specific PDEbody. The format of the PDEbody must follow the same formatting rules
as for the PDEheader. These rules are defined in one or more subordinate specifications attached to this document.
Table 12 PDEbody Class Attributes
Attribute Name Definition Access Reqd Form
none
8.3.8 PDEbodyReference Class
8.3.8.1 When the PDEbody format does not correspond to the same formatting rules (as defined on one or more
subordinate specifications attached to this one) as the PDEheader, it is stored separate from rest of the PDE. In this
case, the PDE has a PDEbodyReference to identify that separate PDEbody.
Table 13 PDEbodyReference Class Attributes
Attribute Name Definition Access Reqd Form
specification Identifies the PDEbody. This is implementation dependent. For
example, it might be a file specification.
RO Y String
bodyChecksum The checksum value calculated for the external PDEbody. RO Y Checksum
8.4 RaP Services
8.4.1 The purpose of this section is to define the message services required to support RAP functionality. Providers
of RaP services are called RaPnodes. This section will define the different kinds of RaPnode and then define the
services provided by each.
8.4.2 All RaP services are based on request/response semantics. Any service may be requested at any time. There
are no state models associated with RaPnodes.
SEMI E139-0705 © SEMI 2005 22
8.4.2.1 RaPnodes
8.4.2.1.1 RaP defines RaPnodes as the providers of RaP services. There are three types of RaPnodes:
EquipmentNodes, FICSnodes, and EditorNodes.
EquipmentNode — The EquipmentNode provides RaP Services for accessing the equipment.
FICSnode — The FICSnode provides RaP Services for accessing the Factory Information and Control System
(FICS).
EditorNode — The EditorNode provides RaP Services for accessing the PDEeditor.
8.4.2.1.2 Figure 8 is a UML class diagram illustrating the relationships of the RaPnodes. As the diagram shows,
there are some services that are common to all RaPnodes. Other services are unique to certain types of RaPnodes.
This is more fully specified in Table 14 below.
8.4.2.1.3 The clients of RaP services can be any entity with communication access to a RaPnode. If the client for
RaP services is also a RaPnode, then more robust interactions are possible with messages initiated from both
RaPnodes. For more discussion on communication scenarios, see Related Information.
FICSnode
deletePDE()
EditorNode
verifyPDE()
deletePDE()
resolvePDE()
EquipmentNode
getPDEdirectory()
getPDEheader()
getPDE()
requestToSendPDE()
sendPDE()
nodeID
RaPnode
Figure 8
RaPnode Class Diagram
8.4.2.1.4 The class diagram also identifies the nodeID attribute (see Table 14). All RaPnodes shall define a nodeID
that can be used for identification in communications. The nodeID is referenced by the createNode attribute of the
PDEheader class.
Table 14 RaPnode Class Attributes
Attribute Name Definition Access Reqd Form
nodeID Identifier of the RaPnode. The nodeID shall be unique within the
factory where it is being used.
RO Y String
8.4.2.2 Required Services Per Node
8.4.2.2.1 As discussed in §2, RaP defines services that apply to three different communication nodes: the FICS, the
Equipment, and the PDEeditor. Each of those nodes is required to provide certain services to be compliant to RaP.
Table 15, Service Descriptions, describes each service defined by RaP and which node must provide that service.
This listing corresponds to the services listed in Figure 8.