semi合集-English.pdf - 第3611页

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 adde d or removed), then the Equ ipmentNode shall no…

100%1 / 7923
SEMI E139-0705 © SEMI 2005 34
8.5.3.1.1 RaP supports a communications structure where all communications between FICS and the Equipment
and PDEeditor are initiated by the FICS.
8.5.3.1.2 Improved efficiencies may be possible when other RaPnodes can utilize FICSnode services. RaP
supports, but does not require this approach.
8.5.3.2 If an FICSnode is provided, it shall support all the services defined for it as noted in Table 15.
8.5.4 EquipmentNode Requirements And Clarifications
8.5.4.1 The Equipment shall provide a single EquipmentNode that supports all the services defined for it as noted in
Table 15.
8.5.4.2 The EquipmentNode shall be able to perform all RaP related activities without the presence of an FICSnode
or an EditorNode (that is, where all communications with the EquipmentNode are initiated by the client).
8.5.4.2.1 The EquipmentNode should provide alternate methods of performing these activities that take advantage
of the services provided by FICSnodes and/or EditorNodes.
8.5.4.3 The EquipmentNode shall supply values for all PDEparameters of the Master PDE as needed by soliciting
these values as input parameters to the definition of processing jobs.
8.5.4.3.1 These input parameters shall have the same name as the corresponding PDEparameters.
8.5.4.4 The equipment supplier shall determine what parameters (that is, Module Parameters) to make available for
setting by the PDEs.
8.5.4.4.1 The equipment supplier shall document all Module Parameters.
8.5.4.4.2 The equipment supplier is encouraged to make available all settings that effect the outcome of processing.
8.5.4.4.3 Some settings, such as calibration settings, may not be accessible for setting by the recipe.
8.5.4.4.4 All collections of settings or instructions (scripts, support files, etc.) associated with the processing
specification shall be PDEs.
8.5.4.4.4.1 If this PDE contains settings not available for editing by the user (for example, calibration values), the
equipment/PDEeditor may place appropriate restrictions on the PDE. For example, there might be a PDE (or PDE
group) that contains calibration values that can be modified only by maintenance personnel and that cannot be
downloaded to the equipment. In some cases, such a calibration PDE is automatically updated just before the run
and can be specified only by gid.
8.5.4.5 The EquipmentNode 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.4.5.1 The suggested method is to embed the uid inside the PDEbody, but this is not a required solution.
8.5.4.5.2 This may also be accomplished by computing the checksum of the PDEbody and comparing it to the
bodyChecksum value contained in the PDE. This method requires no change to the PDEbody.
8.5.4.6 The EquipmentNode shall verify each PDE upon receipt. This verification shall be the equivalent of that
initiated by the verifyPDE() service with verifyType = validity and verifyDepth = single.
8.5.4.6.1 The EquipmentNode shall reject any PDE that fails this verification process.
8.5.4.6.2 The equipment is encouraged to verify any recipes that are placed on the equipment from any source and
via any method (for example, using removable media).
8.5.4.6.3 The equipment is encouraged to verify the Master PDE before execution. It is suggested that the
verification performed be the equivalent of that initiated by the verifyPDE() service with verifyType = checksum and
verifyDepth = all. Note that no results can be reported to the client. Any PDE that fails verification (except for the
non-presence of a referenced PDE) should be removed from the recipe store on the equipment. If possible, a copy
should be kept in a private area for debugging purposes.
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.