semi合集-English.pdf - 第3610页

SEMI E139-0705 © SEMI 2005 34 8.5.3.1. 1 RaP supports a communications structure where a ll communications between FICS and the Equipment and PDEe ditor are initiated by th e FICS. 8.5.3.1. 2 Improved efficiencies m ay b…

100%1 / 7923
SEMI E139-0705 © SEMI 2005 33
Table 27 Manifest Entry Data Definitions
Manifest Data Item Description Format
uid Value of the uid attribute of the PDE contained in the
TransferContainer.
UUID
PDEdescriptor Descriptor of the transfer form of the PDE (for example, a file name). string
PDEbodyDescriptor Descriptor of the transfer form of the PDEbody (for example, a file
name).
string
Location String that indicates the location on the equipment for this recipe. The
format of this string is left to the implementer.
string
8.4.2.13.8 Manifest and the TransferContainer exist only for the purpose of transfer of PDEs. They are not tracked
and cannot be accessed using any RaP defined interfaces outside of the context of the transfer operation for which
they are created.
8.5 RaPnode Requirements and Clarifications
8.5.1 This section defines and clarifies requirements on the RaPnodes.
8.5.2 General RaPnode Requirements And Clarifications
8.5.2.1 A RaPnode is a provider of RaP defined services. Clients of RaP services are not required to be RaPnodes.
However, in many cases RaPnodes will be clients of other RaPnodes.
8.5.2.2 Of the three defined RaPnodes, RaP requires only that an EquipmentNode be present and fully support the
RaP services defined for it.
8.5.2.2.1 The other two types of RaPnodes may be present and if so, they shall fully support the RaP services
defined for them.
8.5.2.3 RaPnodes may be combined into a single node. For example, an EditorNode may be combined with an
EquipmentNode. This combined node shall support the superset of capabilities defined for these two types of nodes.
8.5.2.3.1 The combined RaPnode entity is a single node, therefore there is no requirement that RaP services be used
internally (for instance, between the internal EditorNode and the internal EquipmentNode capabilities).
8.5.2.4 When a PDEbody is opaque to the user (for example, of a binary format), it shall be separated from the
PDE/PDEheader construct as described in ¶8.3.7.
8.5.2.4.1 When the PDEbody is contained within the PDE, it shall meet the same format requirements as the
PDEheader. In this case, its contents shall be comprehensible by the user.
8.5.2.4.2 The format requirements for the PDE are defined in subordinate specifications (sometimes called “dot
standards”).
8.5.2.5 When a
TransferContainer is received, the RapNode shall extract the PDEs and store them in such a way
that each PDE can be exactly re-created for later transfer such that the calculated checksum will be correct.
8.5.2.6 RaP does not address and is not affected by internal design decisions for the Equipment, PDEeditor, and
FICS. It deals only with communication among the Equipment, the PDEeditor, and the FICS.
8.5.2.6.1 For example, a PDEeditor might provide a “thin client” interface in the form of a web browser-based
implementation. RaP does not restrict such designs. In this case, the PDEeditor should still provide a RapNode that
complies with this specification.
8.5.2.7 For all checksum values defined by this specification, the MD5 method for computing checksums shall be
used. MD5 is defined by the IETF (see the reference in §10).
8.5.3 FICSnode Requirements And Clarifications
8.5.3.1 The factory environment is not required to provide a FICSnode or the associated services.
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.