semi合集-English.pdf - 第3613页

SEMI E139-0705 © SEMI 2005 37 Table 28 RaP Compliance T able RaPnode Type: EquipmentNode  EditorNode  FICSnode  Section Topic RaP Complian t PDE Content 8.3 PDE Class Diagram  8.3.1.1 PDE Class  8.3.2 PDEheader Clas…

100%1 / 7923
SEMI E139-0705 © SEMI 2005 36
8.5.5.2.1.5 During the PDE creation process, the PDEeditor shall provide the user the opportunity to enter userInfo
text strings.
8.5.5.2.1.6 The PDEeditor shall enforce restrictions on PDEs in the same group. All PDEs in a group shall have
the same set of PDEparameters and they shall have default values on the same subset of these PDEparameters. The
PDEeditor might need access to a member of the group (or key information from a group member) in order to
create a new member.
8.5.5.2.1.7 When the PDEeditor creates a new PDE the following shall be true with regard to PDE groups:
8.5.5.2.1.7.1 The PDEeditor that creates the PDE shall determine the gid during PDE creation
8.5.5.2.1.7.2 The PDEeditor shall determine (based on user input) whether a PDE will join an existing PDE group
and if so, will enforce the rules for PDEs that are in the same group (see ¶8.3.2 for more information).
8.5.5.2.1.7.3 In all other cases, the gid shall be a new uuid value generated at recipe creation time (distinct from the
uid).
8.5.5.2.1.8 During the PDE creation process, the PDEeditor shall allow the user the option of setting
ExecutionTargets or omitting them. ExecutionTargets are intended to ensure that PDEs are executed on the correct
equipment. By omitting the ExecutionTargets, the user chooses to bypass this protection by the equipment.
8.5.5.2.1.9 The PDEeditor shall allow the user to define the PDEparameters for a PDE and when, during
processing, these PDEparameters shall be applied.
8.5.5.3 EditorNode
8.5.5.3.1 This section discusses requirements and clarifications related to communication with an EditorNode.
8.5.5.3.1.1
If EditorNode(s) are provided, each shall support all the services defined for it as noted in Table 15.
8.5.5.3.1.2 An EditorNode may choose to communicate with an EquipmentNode using RaP services, but it is not
required to do so.
8.5.5.3.1.2.1 A proprietary interface may be used between PDEeditor and Equipment.
8.5.5.3.1.2.2 In either case, the equivalent of all RaP services defined between EditorNode and EquipmentNode
shall be provided.
8.5.5.3.1.3 The EditorNode shall be able to perform all RaP related activities without the presence of a FICSnode
(that is, where all communications with the FICS are initiated by the FICS).
8.5.5.3.1.3.1 The EditorNode should provide alternate methods of performing these activities that take advantage of
the presence of a FICSnode. For example, at the PDEeditor, human triggered (EditorNode initiated) PDE upload
may be supported.
8.5.5.3.1.4 The EditorNode can create a new PDE group at any time. There are no restrictions.
9 Compliance
9.1 Table 27 is intended to be used to document compliance to RaP. One copy of the table shall be completed per
RaPnode to be implemented.
9.2 The first row of the table declares the type of RaP node to be delivered. The proper box shall be checked.
Where two types of RaP node are combined, two boxes shall be checked. The combination of Equipment and FICS
is not allowed.
9.3 Each (non-header) row in the table references a subsection number from §8 (RaP Requirements). A check in
the checkbox for the “RaP Compliant” column shall indicate that all requirements in the named subsections for that
row (and their subsections) are met.
9.4 For an equipment to be considered RaP compliant, it shall supply an EquipmentNode that complies with all
applicable RaP requirements and in addition, all EditorNodes that are supplied (if any) shall be RaP compliant.
SEMI E139-0705 © SEMI 2005 37
Table 28 RaP Compliance Table
RaPnode Type: EquipmentNode EditorNode FICSnode
Section Topic RaP Compliant
PDE Content
8.3 PDE Class Diagram
8.3.1.1 PDE Class
8.3.2 PDEheader Class
8.3.3 AntecedentData Class
8.3.4 ReferencedPDE Class
8.3.5 ExecutionTarget Class
8.3.6 PDEparameter Class
8.3.7 PDEbody Class
8.3.8 PDEbodyReference Class
RaPnode Requirements
8.5.2 General RaPnode Requirements
8.5.3 FICSnode Requirements
8.5.4 EquipmentNode Requirements
8.5.5 EditorNode Requirements
RaP Services Requirements
8.4.2.1 RaPnodes
8.4.2.2 Required Services Per Node Compliance represented in service compliance below.
8.4.2.3 Service Message Parameters
Compliance noted below for each service using these
parameters.
8.4.2.5 getPDEdirectory()
8.4.2.6 deletePDE()
8.4.2.7 getPDEheader()
8.4.2.8 getPDE()
8.4.2.9 requestToSendPDE()
8.4.2.10 sendPDE()
8.4.2.11 resolvePDE()
8.4.2.12 verifyPDE()
8.4.2.13 TransferContainer
10 Related Documents
Grady Booch, James Rumbaugh, and Ivar Jacobson, The Unified Modeling Language User Guide,
Reading
Massachusetts, Addison Wesley: 1999 ISBN 0-201-57168-4.
Rivest, Ronald, The MD5 Message-Digest Algorithm,
IETF RFC: 1992 http://www.ietf.org/rfc/rfc1321.txt.
Uniform Resource Name (URN) Syntax, IETF RFC 2141, May 1997
http://www.ietf.org/rfc/rfc2141.txt.
SEMI E139-0705 © SEMI 2005 38
RELATED INFORMATION 1
NOTICE: This related information is not an official part of SEMI E139 and was derived from North American
Information and Control Committee. This related information was approved for publication by full letter ballot on
December 10, 2004.
R1-1 Scenarios
R1-1.1 This section contains example scenarios to illustrate how RaP services might be used in practice. They
represent only a subset of possible scenarios. The purpose of including these scenarios is to demonstrate how the
RaP services can work together to perform complex tasks.
R1-1.1.1 For these scenarios, certain assumptions were needed about how business rules of the FICS and about the
outcome of certain services. These assumptions are stated. The FICS business rules are not intended to represent
actual factory systems. Instead, they are designed to demonstrate possible combinations of services to perform a
task. RaP is intended to work with a wide range of FICS business rules. It is not possible to demonstrate all
situations.
R1-1.1.2 Assumptions for all scenarios: (unless otherwise noted in the individual scenario)
Equipment, Editor, and FICS nodes are separate nodes that communicate via RaP services (note that Equipment
to Editor communications are not required to use RaP services).
The "User" entity represents any source of stimulus, human or electronic.
All message receive positive or "success" (response unless otherwise noted).
The provided scenarios may not be the only way to accomplish each task. This set is not meant to be
exhaustive.
Response messages are not shown unless they add information for the reader.
R1-2 Scenario – Download PDEs
R1-2.1 This scenario is representative of most uses of the sendPDE() service.
R1-2.1.1 Assumptions:
The PDEs to be downloaded are not currently stored on the equipment.
Ed it o r FICSEquipmentUser
Create TransportContainer
requestToSendPDE()
sendPDE()
sendPDE()- rsp
Verify is automatic
with
verifyType=validity,
verifyDepth=single
Dow nload Unrelated PDE's
Unpack TransportContainer
Verify All New PDE's
Figure R1-1