semi合集-English.pdf - 第3609页

SEMI E139-0705 © SEMI 2005 33 Table 27 Manifest En try Data Definitions Manifest Data Item Description Format uid Value of the uid attribute of the PDE contained in the TransferContainer. UUID PDEdescriptor Descriptor of…

100%1 / 7923
SEMI E139-0705 © SEMI 2005 32
8.4.2.13 TransferContainer
8.4.2.13.1 Some of the RaP services reference a TransferContainer. This section defines the TransferContainer.
8.4.2.13.2 The TransferContainer bundles one or more PDEs together for transfer. This provides messaging
efficiency, logical grouping of PDEs where appropriate, and also creates a potential for data compression of the
PDEs.
8.4.2.13.3 This specification allows any combination of PDEs to be included in the TransferContainer. They need
not be related. However, the user may choose logical groupings. For instance, the FICS may choose to always
download Master PDEs and all their related PDEs together.
8.4.2.13.4 The details of data compression are left as an implementation decision. For example, if the
implementation chose to represent PDEs as files, it might be logical to implement the TransferContainer in the form
of one of the popular file compression formats.
TransferContainer
PDE
PDE
PDE
PDEbody
PDEbody
PDEbody
Manifest
uid PDE PDEbody Location
xxx abc.xml abc.dat \production
yyy mno.xml <none> \maintenance
…
TransferContainer
PDE
PDE
PDE
PDE
PDE
PDE
PDEbody
PDEbody
PDEbody
PDEbody
PDEbody
PDEbody
Manifest
uid PDE PDEbody Location
xxx abc.xml abc.dat \production
yyy mno.xml <none> \maintenance
…
Figure 9
TransferContainer Illustration
8.4.2.13.5 Figure 9 provides an illustration of a TransferContainer. It contains a set of PDEs, a set of independent
PDEbodies (as needed) and a Manifest that describes the contained PDEs.
8.4.2.13.6 The PDEs and the PDEbodies are in document form for transfer. The form of these documents is left as
an implementation detail. It is assumed that the document form of the PDE will have some sort of descriptor (for
example, a filename).
8.4.2.13.7 The Manifest associates the uid of each PDE contained with the descriptor of the document form of that
PDE and the descriptor of its corresponding PDEbody (if not contained inside the PDE). It is arranged as a series of
entries, each of which contains a single uid, the descriptor of the corresponding PDE, the descriptor of the PDEbody
(if applicable), and a Location string. The Location string is not required, but it allows the client to specify where
the recipe is to be stored (or the equipment to specify where it had been stored). The format of the Location string is
supplier specified. Each of these entries in the Manifest allows the receiver of the Transfer Container to quickly
identify the PDE, find its corresponding PDEbody, and store it appropriately. See Table 27 for more information on
Manifest entry data.
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.