semi合集-English.pdf - 第3608页

SEMI E139-0705 © SEMI 2005 32 8.4.2.13 TransferCon tainer 8.4.2.13 .1 Some of t he RaP services reference a TransferC ontainer . This section defines the T ransferContainer . 8.4.2.13 .2 The Transfer Container bundles on…

100%1 / 7923
SEMI E139-0705 © SEMI 2005 31
during this process, the EquipmentNode encounters any of the gids listed in the inputMap, it shall use the
corresponding uid from the inputMap in its resolution. This inputMap allows the client to override the normal
resolution method by the equipment (see ¶8.5.1.3).
8.4.2.11.5 Some gids listed in the inputMap may not be encountered during the resolution process. This is not
considered an error and shall be ignored by the EquipmentNode. If a gid from the inputMap appears in the recipe
hierarchy, but the corresponding uid is not available on the equipment, then the EquipmentNode shall note the
situation as an error (see resPDEstat) and resolve that gid as if it had not appeared in the inputMap.
8.4.2.11.6 If ResolvePDEreferences is set to false (see ¶8.5.1.3), then only the entries in the inputMap are used to
resolve the specified PDE. In this case, if a needed gid reference in the recipe structure is not included in the
inputMap, it shall be treated the same as if no member of the group were available in the equipment store of PDEs
(resPDEstat = MissingReferencedPDE).”
8.4.2.11.7 The outputMap parameter lists each PDE reference found during the resolution process and the
resolution for each. The targetPDE is a PDE reference and shall be included in the outputMap. The targetPDE
may contain a gid value.
8.4.2.11.8 If any gid from the recipe structure cannot be resolved to a uid, that gid shall appear in the outputMap
with a zero length string for the corresponding uid. This error shall also be noted in resPDEstat.
8.4.2.11.9 All
outputMap values that contain no errors shall be acceptable to the equipment as inputMap or
PDEmap values.
Table 25 resolvePDE() Service Parameters
Parameter Name Req/Ind Rsp/Cnf Comment
targetPDE M - The uid or gid of the PDE to be resolved.
inputMap M - Client specified resolutions for selected PDE references.
outputMap - M Service provider generated list of all PDEs referenced in the recipe
hierarchy beneath (and including) the targetPDE.
resPDEinfo M Report any problems resolving the PDE references.
8.4.2.12 verifyPDE()
8.4.2.12.1 The verifyPDE() service is used to check the validity of a specified PDE. It may be used to check a
single PDE or all PDEs that it directly or indirectly references (see verifyDepth). Multiple levels of verification are
available (see verifyType). The highest level, “Validity” is dependent on the supplier. The supplier shall document
the verification steps it takes when verifyType is set to “Validity”.
8.4.2.12.2 The verification process yields only the current status of a PDE. A successful verification does not
guarantee that a later verification (or execution) will succeed.
8.4.2.12.3 Verification results shall be independent of the status of the equipment and its components. For example,
if a processing module is out of service, it shall not change the outcome of the verification process. Equipment
status is out of scope of this specification.
8.4.2.12.4 When verifyDepth is “All”, the verifyPDE() service must resolve any PDE references that contain gids.
The inputMap parameter allows the client to specify the resolution for some or all of these gids.
Table 26 verifyPDE() Service Parameters
Parameter Name Req/Ind Rsp/Cnf Comment
targetPDE M - The uid of the PDE to be verified.
inputMap M - Client specified resolutions for selected PDE references.
verifyType M - Which type of verification to be done.
verifyDepth M - Should referenced PDEs also be verified?
verifySuccess - M Overall success or failure.
verifyInfo - M Lists results of the verification for each PDE.
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.