semi合集-English.pdf - 第3445页

SEMI E133-0705 © SEMI 2004, 2005 26 10.5.1 R2R Control AE Method Capabilities 10.5.1.1 No method capabilities for thi s AE type are specified. 10.5.2 R2R Control AE Behavior 10.5.2.1 The R2R control behavior defines the …

100%1 / 7923
SEMI E133-0705 © SEMI 2004, 2005 25
# Description Req’d Comments
SPC.A.7
Ability to store user problem resolution comments
Provide a place for users to put in comments on how the problem
was corrected. This may also be used by the statistical analysis
system to store information related to the OOC point to speed
diagnosis and problem resolution.
N
10 Method Capabilities and Behavior
10.1 All PCS functional groups inherit certain capabilities, methods, and behavior from the general PCS Interface.
This interface provides support primarily for general execution and publish/subscribe communications.
Publish/subscribe is a type of communications where data produced by an application process can be consumed by a
number of application processes that belong or “subscribe to” the communication environment. Additional
information on the publish/subscribe communications approach can be found in reference §4.
10.2 This standard specifies both required ‘methods’ as well as ‘capabilities’, which must be supported by any PCS
Analysis Engine. Support for the required methods must use the defined method names, as well as the specified
argument and return data types. Most Arguments and Returns must be of the type AnalysisEngineDataSet. The
AnalysisEngineDataSet type is a set of aggregate data structures as defined in §9. Support for the stated “methods”
must be provided as specified. Support for “method capabilities” must be provided by any PCS-conformant
functional group, but how these capabilities are supplied – including specific arguments and returns, method,
argument and return names, and argument and return data types - are either beyond the scope of this standard or
specified elsewhere in this standard, e.g., in specification of the interface data structure. The data types used as the
Arguments and Returns for each capability are general data types, and are guidelines only.
10.3 The general PCS Interface required methods and capabilities are summarized in the table below and described
more fully in the accompanying sections.
10.4 Common Analysis Engine Method Capabilities and Behavior
10.4.1 Common Analysis Engine Method Capabilities
10.4.1.1 The capabilities described in the following section and Table XYZ are required in any PCS-compliant
Analysis Engine. However, the form of their implementation is not a part of this standard. The approach by which
the method capability is accessed by a client, be it via method invocation, database queries and triggers, etc, is
subject to the decisions of the implementer. Also, the exact data types used for the Arguments and Returns are up to
the developer. Additional arguments or return types may also be required depending on the implementation
technology.
10.4.1.2 These method capabilities are generalizations of “Publish/Subscribe” interfaces. Note that there is not
necessarily a one-to-one correspondence between method capabilities as defined herein and methods in an
implementation of these capabilities.
Table 22 Common PCS Analysis Engine Method Capabilities
# Capability Req’d Behavior/Comment
1 Produce Log
Data
Y Allows a client to have access to logging information conveyed through the log messages of
the PCS compliant analysis engine. Arguments passed with a log data request could relate
the date range and context associated with the request, while information returned could
include the status along with the requested log data.
2 Produce
Exception Data
Y Allows a client to access or be informed of exceptions raised by the PCS system. The
exception information would be returned by the AE to the requestor, and could include a
date range, similar to log data.
10.4.2 Common Analysis Engine behavior
10.4.2.1 No additional common AE behavior is specified.
10.5 R2R Control AE Method Capabilities and Behavior
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.