semi合集-English.pdf - 第3446页

SEMI E133-0705 © SEMI 2004, 2005 27 11.3.3 Compliance verification will not address the fo llowing:  Engine respo n se to im properly formatte d inputs  Quality of Service (QoS) of data in output structures prod uced b…

100%1 / 7923
SEMI E133-0705 © SEMI 2004, 2005 26
10.5.1 R2R Control AE Method Capabilities
10.5.1.1 No method capabilities for this AE type are specified.
10.5.2 R2R Control AE Behavior
10.5.2.1 The R2R control behavior defines the operation of the R2R Control AE in providing capabilities. The
interface (methods, capabilities and behavior) is inherited from the common PCS interface. Inherited methods are
identical in form to the methods required in the Analysis Engine interface. However, their implementation is specific
to R2R Control analysis engines.
10.5.2.2 If a R2R AE receives an input message of type AnalysisEngineDataSet for a process control job, and, in a
PCSAETarget attribute of that message, one of the list of instructions in the Instructions attribute has a value of
“R2RCalculateControlAdvice”, then the R2R control AE shall provide an output message of type
AnalysisEngineDataSet that contains the data item name “ControlAdvice” in a DataCollection where BinCategory
== “CalculatedOutputs”.
10.5.2.3 If a R2R AE receives an input message of type AnalysisEngineDataSet for a process control job, and, in a
PCSAETarget attribute of that message, one of the list of instructions in the Instructions attribute has a value of
“R2RUpdateModel”, then the R2R control AE shall utilize information provided as part of the associated PCS job to
update control models as necessary. The determination of need to update models and the method in which these
models are updated is beyond the scope of this standard.
11 Compliance to PCS Standard
11.1
This section defines requirements placed on process control systems for claiming compliance with this
standard and verifying compliance with this standard. The standard does NOT include specific verification test
plans, but there should be enough information in the standard to generate these.
11.2 Approach
11.2.1 This standard specifies the interfaces for PCS functional groups. Compliance with this standard is verified
through testing these interfaces to verify compliance of data structures and behavior to the extent specified in this
standard.
11.2.2 As noted in §9, all PCS Analysis Engines are characterized as having a set of capabilities, and a collection of
inputs and outputs, with the outputs being a function of the inputs. The general approach to compliance testing then
is to first document the capabilities, and then test the inputs and outputs by (1) generating inputs for the PCS
Analysis Engine to consume and (2) observing corresponding outputs of the engine. It is understood that there are a
number of behavior models that an Analysis Engine shall use to consume inputs and produce outputs, such as active
polling by the engine or a request message from an outside source to the Analysis Engine. The compliance testing
method should utilize a mechanism that works with the behavioral model of the Analysis Engine for subscription to
(i.e., consumption of) inputs and publication of (i.e., production of) outputs.
11.2.3 Note also that all PCS Analysis Engines inherit a set of common requirements. Thus, the approach for
testing any PCS Analysis Engine should be to first verify compliance to the common requirements, and then verify
compliance to the requirements specific to the particular functional group.
11.3 Scope of Compliance Verification
11.3.1 Compliance Verification shall address the following:
Documentation of functional group capabilities
11.3.2 Future version of this standard will also address the following compliance verification:
Capability to accept all required inputs
Capability to accept properly formatted interface data structures
Capability to produce all required outputs; these outputs may be in response to the inputs as specified herein
Capability to produce properly formatted output data structures
SEMI E133-0705 © SEMI 2004, 2005 27
11.3.3 Compliance verification will not address the following:
Engine response to improperly formatted inputs
Quality of Service (QoS) of data in output structures produced by engine
Quality of Performance (QoP) of engine in producing output structures (e.g., in response to receipt of input
structures)
11.4 Statement of Compliance (SoC): Functional Group Capabilities Data Sheet
11.4.1 All PCS Analysis Engines claiming compliance with this standard are required to be delivered with a
statement of compliance sheet on functional group capabilities. This sheet specifies for the user which functional
capabilities, specified as required or conditional in this standard, are available with this engine. The format of the
SoC sheet is given in Table 21, which includes a description of the fields of this sheet:
Table 23 PCS Analysis Engine SoC Functional Group Capabilities Data Sheet
Company
Company Name
Product
Product Name
Version
Software Revision Number, etc.
Functional Group(s)
Functional Group(s) to which Compliance is claimed
Functional Group Capabilities
- Functional Group #1
# Description Requirement Supported Comments
- Functional Group #2
# Description Requirement Supported Comments
11.4.2 Company — Name of company supplying product.
11.4.3 Product — Name of product being supplied.
11.4.4 Version — Any additional descriptors that supplier applies to product (such as software revision number)
that, along with Product Name, uniquely identifies product.
11.4.5 Functional Group(s) — The functional groups, as defined in this standard, to which compliance is being
claimed.
11.4.6 Functional Group Capabilities — The functional group capabilities as specified in this standard for the
functional group(s) to which compliance is being claimed (as indicated in the “Functional Group(s)” field). Note
that all capabilities specified in this standard for the functional groups, to which compliance is being claimed, must
be listed, and are organized by the fields below.
11.4.7 Functional Group #n — The name of the ‘n-th’ functional group to which compliance is being claimed, e.g.,
“R2R”, “FD”, “FC”, “FP”, or “SPC”.
11.4.8 # — The index number (copied from the “#” field for that capability).
11.4.9 Description — The functional group capability description copied verbatim from this standard (copied from
the “Description” field for that capability), for the PCS analysis engine functional group listed.
11.4.10 Requirement — The requirement of the capability as defined in this standard (copied from the
“Requirement” field for that capability).
11.4.11 Supported — This field contains the PCS analysis engine provider’s claim of support of this capability.
The claim could be “Yes” (“Y”), “No” (“N”), “Conditional” (“C”), or “Optional” (“O”). Note that if the capability
is listed as a requirement then it must be supported.
SEMI E133-0705 © SEMI 2004, 2005 28
11.4.12 Comment — This field contains any additional information that the PCS analysis engine provider may wish
to provide. Note that if the “Supported” field is listed as “Conditional” or “Optional”, the conditionality or
optionality conditions must be delineated in this field.
11.5 PCS Analysis Engine Compliance Verification Procedure
11.5.1 The following procedure should be applied to all PCS Analysis Engines:
11.5.2 Compliance: Functional Group Capabilities Data Sheet Verification Test:
Is a properly formatted SoC data sheet supplied with product?
Pass Criteria:
A properly formatted SoC data sheet, as specified in ¶11.3 is provided with product.
The Product + Version fields uniquely identify product.
At least one functional group is claimed, i.e., the engine declares to belong to at least one functional group as
specified in this standard.
All functional group capabilities for each functional group claimed in the “Functional Group” field are listed as
defined in §9, and the requirement field matches that provided for each capability in §9.
For each capability listed as required, it must also be supported (i.e., if Requirement == ‘Y’, then Supported
==’Y’).
For each capability listed as conditional, the conditions, defined in §9, must be met.
For each capability listed as optional (i.e., not required), a declaration of whether the requirement is supported
must be made (i.e., the “Supported” field for this requirement must be filled in).
11.6 Condition of Compliance
11.6.1 A PCS Analysis Engine can be considered to be compliant with this standard if and only if it passes all of the
compliance tests for the Analysis Engine in ¶11.5.
NOTICE: SEMI makes no warranties or representations as to the suitability of the guidelines set forth herein for
any particular application. The determination of the suitability of the standard is solely the responsibility of the user.
Users are cautioned to refer to manufacturer's instructions, product labels, product data sheets, and other relevant
literature, respecting any materials or equipment mentioned herein. These standards are subject to change without
notice.
By publication of this guideline, Semiconductor Equipment and Materials International (SEMI) takes no position
respecting the validity of any patent rights or copyrights asserted in connection with any item mentioned in this
guideline. Users of this guideline are expressly advised that determination of any such patent rights or copyrights,
and the risk of infringement of such rights are entirely their own responsibility.
Copyright by SEMI® (Semiconductor Equipment and Materials
International), 3081 Zanker Road, San Jose, CA 95134. Reproduction of
the contents in whole or in part is forbidden without express written
consent of SEMI.