semi合集-English.pdf - 第3598页

SEMI E139-0705 © SEMI 2005 22 8.4.2.1 RaPnodes 8.4.2.1. 1 RaP defines RaPnodes as the providers of RaP servi ces. There are three types of RaPnodes : EquipmentNodes , FICSnodes , and EditorNodes .  EquipmentNode — The E…

100%1 / 7923
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.
SEMI E139-0705 © SEMI 2005 23
8.4.2.2.2 The Service Descriptions table has six columns:
The first column lists the services.
The second column defines the type of service. This may be a request/response message pair (denoted by “R”)
or a notification message (denoted by “N”).
The third column is a textual description of the service.
Columns 4–6 each represent a RaP communication node. For each service, a checked box in this column
indicates that the node is required to provide this service. An empty box indicates that the service shall not be
provided.
Table 15 Service Descriptions
Service Name Type Description Equipment FICS Editor
getPDEdirectory() R
This service requests a list of the PDEs managed
by the RaPnode. The requestor may supply
selection criteria for which PDEs to re
p
ort and may
also select certain attributes to be returned for each
reported PDE.
deletePDE() R
This service requests the service provider to delete
the specified PDE(s) from the RaPnode.
getPDEheader() R
This service requests the service provider to return
the complete header of the specified PDE(s).
getPDE() R
This service requests the service provider to return
the specified PDE(s) in a TransferContainer.
requestToSendPDE()
R
This service requests the service provider to grant
or deny permission to transfer a collection of PDEs
in a TransferContainer to the service provider.
sendPDE() R
This service requests the service provider to accept
the set of PDE’s in the included
TransferContainer.
resolvePDE() R
This service requests the service provider to
determine the complete recipe hierarchy beneath
the specified PDE based on the ReferencedPDEs.
verifyPDE() R
This service requests the service provider to check
various aspects of the specified PDE.
8.4.2.3 Service Message Parameters
8.4.2.3.1 The following service parameter dictionary (Table 16) defines the name, description, and format for
parameters used by RaP services. The format column uses data types defined in ¶6.2.5.1.3.
Table 16 Service Parameter Dictionary
Parameter Name Form Description Where Used
delRspInfo
list of (uid, delRspStat)
Contains a list of the status for each specified PDE
(as identified by the uid).
deletePDE()