semi合集-English.pdf - 第3444页

SEMI E133-0705 © SEMI 2004, 2005 25 # Description Req’d Comments SPC.A.7 Ability to store user proble m resolution comments Provide a place for users to put in comments on h ow the problem was corrected. This may also be…

SEMI E133-0705 © SEMI 2004, 2005 24

# Description Req’d Comments

SPC.I.7

Basic Model Management

The SPC Analysis Engine shall provide the capability to

create/add models, edit configuration of models, and delete

models.

Y This capability will be supported through

the FD Analysis Engine interface.

SPC.I.8

Interface with other Analysis Engines

The SPC Analysis Engine shall be capable of either accepting

outputs from other Analysis Engines as inputs, or producing

outputs that are utilized by other Analysis Engines.

SPC.I.9

Advanced Model Management

The SPC Analysis Engine may provide advanced model

management capabilities including but not limited to: secure

access to models, and automatic updating of models based on

process control environment changes.

SPC.I.10

Provide the optional PCS Analysis Engine method capabilities

The PCS Analysis Engine shall provide all or a subset of the

optional interface method capabilities as defined in this standard.

Table 21 Additional SPC Functional Group Capabilities

# Description Req’d Comments

SPC.A.1

Ability to perform trend analysis

Automated analysis of data for the identification of undesired trends

using industry standard run rules such as (for example) Western

Electric. One result of these calculations and comparisons should be

a decision of whether or not the new data caused the “chart” to go out

of control. The mathematics available must include those items

listed in #SPC.A.4 below.

SPC.A.2

Ability to support standard control charts

Provide ability to plot data as well as display traditional variables

charts, and attributes charts. The system should also provide access

to the data to enable a third party system to display control charts.

SPC.A.3

Ability to perform statistical analysis

These tools may include the ability to calculate statistical metrics,

normal analysis, and non-normal analysis.

SPC.A.4

Ability to calculate control limits

The calculation of control limits for control charts from historical

data using industry standard techniques for calculating upper and

lower control limits for variables and attributes charts based on sub-

group size, sample size, etc.

SPC.A.5

Provide an interface for automatic notification of processing

anomalies

The system must provide an interface to automatically notify an

external system when an assignable cause statistical anomaly is

detected. The interface must provide enough information about the

detected problem for the external system to make decisions about

notification.

Y The external system may for example:

page or e-mail an engineer, or take the

tool in question off-line. Information

provided in the interface should

include: context, severity, and any

fault details.

SPC.A.6

Ability to provide a reference to an Out-of-Control Action Plan

The system should store the action plan that is to be put into effect in

the case of the trend analysis determining that an out of control

condition exists. Ideally this would have at least a full page of

storage and an optional URL linking capability (reference being web

link).

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.

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

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