semi合集-English.pdf - 第3607页

SEMI E139-0705 © SEMI 2005 31 during this process, the EquipmentNode encoun ters any of the gid s listed in the inputMap , it shall use the corresponding uid from the inputMap in its resolution. This inputMap allo ws the…

100%1 / 7923
SEMI E139-0705 © SEMI 2005 30
transferContainer - C The actual TransferContainer. It is included only if PDEs are returned as a
result of the request.
getRspInfo - M Report success or failure for each requested PDE.
8.4.2.9 requestToSendPDE()
8.4.2.9.1 Request for permission to send a TransferContainer containing PDEs to the service provider. The size of
the proposed TransferContainer is provided so that the service provider can ensure that room is available.
8.4.2.9.2 The response to the request is contained in the rtsRspStat. If the returned value is “OK”, the service
provider is indicating that the proposed sendPDE() service should succeed. The requestToSendPDE() service shall
not be required to be send prior to the sendPDE() service. It provides an opportunity to check on a proposed transfer
before that transfer is attempted.
8.4.2.9.3 The tcid appears in both the requestToSendPDE() and sendPDE() services. This provides a way for the
RaPnode to match a received TransferContainer with the earlier requestToSendPDE() message.
Table 23 requestToSendPDE() Service Parameters
Parameter Name Req/Ind Rsp/Cnf Comment
tcid M = Identification of the TransferContainer to be transferred.
transferSize M - Size of the TransferContainer in bytes.
rtsRspStat - M Response to the request to send.
8.4.2.10 sendPDE()
8.4.2.10.1 The sendPDE() service is used to transfer PDEs contained in a TransferContainer to the service
provider. Any response other than success (“OK”) shall be considered an indication that the recipe was not
accepted. If a duplicate PDE is contained in the TransferContainer, the service provider shall store one and discard
the other. This shall not be considered an error. If a PDE in the TransferContainer is already stored on the service
provider, the newly received PDE shall overwrite the existing one.
8.4.2.10.2 Refer to ¶8.5.1.3 for requirements related to PDE transfer that apply to EquipmentNodes.
Table 24 sendPDE() Service Parameters
Parameter Name Req/Ind Rsp/Cnf Comment
tcid M - Identifier of the TransferContainer being sent.
transferContainer M - The actual TransferContainer being transferred.
sendRspInfo - M Report success or failure for each PDE.
8.4.2.11 resolvePDE()
8.4.2.11.1 In the recipe hierarchy, each reference of a PDE is either a uid or a gid value. All gids must be resolved
to uids before a recipe can be executed. The EquipmentNode is responsible for the final resolution of any gids not
resolved by the client (see ¶8.5.4). The resolvePDE() service is a request for the EquipmentNode to provide the
resolution of all gids in a hierarchy. The EquipmentNode shall resolve the recipe hierarchy exactly the same as if the
recipe was to be executed at the time of the resolvePDE() request.
8.4.2.11.2 The structure of a recipe can be determined by successively resolving the ReferencedPDEs at a level of
the hierarchy and then moving downward to the next level. Note that the resolution of a gid at one level will affect
the recipe structure at the next level down. The response to the resolvePDE() service shall comprehend the entire
hierarchy below the targetPDE.
8.4.2.11.3 While the targetPDE will typically be a Master PDE, there is no requirement for this to be the case. This
service can be used to resolve a subset of a complete recipe. The targetPDE shall contain a gid or a uid value.
8.4.2.11.4 The inputMap parameter specifies a list of PDE references with the corresponding uid that resolves each.
This is a list of client specified resolutions for the gids that may be encountered during the resolution process. If,
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.