semi合集-English.pdf - 第3612页

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 PD…

100%1 / 7923
SEMI E139-0705 © SEMI 2005 35
8.5.4.7 The EquipmentNode shall monitor the collection of PDEs available at the equipment. When the collection
changes (that is, a PDE is added or removed), then the EquipmentNode shall notify the FICS via the event data
collection mechanism available on that equipment. Two events shall be defined to support this capability:
PDEadded and PDEremoved. When multiple PDEs are added or deleted at the same time, the change shall be
reported with a single event. A data collection parameter, PDElist, shall be provided to contain list of the uid’s of
the affected PDEs.
8.5.4.7.1 The EquipmentNode shall define a Status Variable that contains the time and date of the last change of the
recipe collection on that equipment. This Status Variable shall be accessible by the FICS (for example, using the
S1,F3/F4 message defined in SEMI E5).
8.5.4.7.2 In the event that a client is disconnected from the EquipmentNode and then reconnected, the client may
check the above resynchronize by using the getPDEdirectory() service.
8.5.4.8 The EquipmentNode shall provide a configurable Boolean setting named “ResolvePDEreferences”.
8.5.4.8.1 This setting shall be configurable by the FICS (for example, using the S2,F15/16 message defined in
SEMI E5).
8.5.4.8.2 If ResolvePDEreferences is set to “True”, the EquipmentNode shall resolve any PDE references left
unresolved by the client when executing a recipe or processing the resolvePDE() and verifyPDE() services. When
the EquipmentNode is required to resolve any unresolved gid’s, it shall select the available PDE with the same gid
that has the newest createDate. In the rare instance that more than one PDE has the same (newest) creation date, the
equipment shall select one whose uid value comes first alphanumerically.
8.5.4.8.3 If ResolvePDEreferences is set to “False”, the EquipmentNode shall not resolve any PDE reference.
8.5.4.9 The EquipmentNode shall provide a predefined input parameter (Variable Parameter) for any job that
executes a recipe consisting of PDEs. This Variable Parameter shall be named “PDEmap”. The equipment client
shall be allowed to supply this value during definition of the job. The format of the PDEmap shall be the same as
the inputMap and outputMap parameters of the resolvePDE() service (see ¶8.4.2.3).
8.5.4.9.1 The PDEmap parameter value shall be used by the equipment to resolve the recipe structure to be used for
the corresponding job. This process is the same as that used for the resolvePDE() service.
8.5.4.10 The Equipment shall provide at least one entity capable of creating PDEs (for example, PDEeditor), either
a) on the equipment or b) directly communicating with the equipment
8.5.4.10.1 This PDEeditor shall be capable of adding or removing PDEs to the equipment’s storage area. This may
be done with RaP compliant services or by proprietary means. This requirement may also be met by having the
PDEeditor and Equipment share storage space.
8.5.5 PDEeditor and EditorNode Requirements And Clarifications
8.5.5.1 A PDEeditor is any entity that can create PDEs. An EditorNode is a PDEeditor that supports RaP services.
Not all PDEeditors are EditorNodes.
8.5.5.2 PDEeditor
8.5.5.2.1 This section discusses requirements and clarifications related to the creation of PDEs.
8.5.5.2.1.1 A PDEeditor shall be capable of creating and modifying all PDEs needed by the equipment.
8.5.5.2.1.2 For any recipe it creates, the PDEeditor shall ensure that any ExecutionTarget definition shall describe
only equipment that are able to execute this PDE.
8.5.5.2.1.2.1 The ExecutionTarget attributes of supplier, make, model, and recipeType are used for this purpose.
8.5.5.2.1.3 All PDEeditors
shall be able to positively confirm the association of a PDEheader to its external
PDEbody based on matching of information contained in the PDEbody with public information contained in the
PDEheader.
8.5.5.2.1.4 RaP does not restrict recipe creation to EditorNodes nor to only RaPnodes. Recipes can be created by
any entity so long as the resulting PDE(s) meet all requirements of this specification.
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.