semi合集-English.pdf - 第3477页

SEMI E134-0305 © SEMI 2004, 2005 30 consumer with sufficient pri vilege (see Section 10) using the DataCollectionManager’s ActivatePlan and GetPlanDefinition operations, resp ectively. Built-in DCPs cannot be deleted by …

100%1 / 7923
SEMI E134-0305 © SEMI 2004, 2005 29
Operation No Privilege ManageOnly-
AuthoredDCPs
UseAnyDCP ManageAny-DCP
GetCurrentPerformanceStatus Equipment shall reject
request with
Unauthorized-Operation.
No restriction. No restriction. No restriction.
11 Data Collection Plan Definition
11.1 DataCollectionPlan
11.1.1 Figure 19 illustrates how a data acquisition consumer can specify to the equipment what data should be
reported for a specific plan.
id
name
desc ript ion
intervalInMinutes
isPersist ent
DataCollectionPlan
sourceId
eventId
EventRequest
eventRequests
1
0..*
id
interv alInSeconds
collectionCount
groupSize
is Cy clical
TraceRequ est
traceReques ts1
0..*
sourceId
exc eptionId
severity
Excep tionRequest
ex ceptionRequest s
1
0..*
sourceId
paramet erName
ParameterRequest
paramet erReques ts
1
1.. *
paramet erReques ts1
0..*
s ourceI d
eventId
Even tTrigger
startOn
1
0..*
stopOn1
0..*
Trigger
sourceId
exceptionId
exceptionStat e
Excepti on Tri g ger
{ordered}
{ordered}
Figure 19
Data Collection Plan
11.1.2 DataCollectionPlan — A data collection plan has a consumer-defined (or supplier-defined, in the case of
built-in DCPs) name and id, and acts as a container for classes that describe what trace data, exceptions, and events
are to be reported to the consumer, as well as any buffering policy for the plan.
11.1.2.1 Built-in DCPs — Equipment suppliers may provide pre-defined DCPs that are included with the
equipment, and don’t require definition by a consumer. Such DCPs shall be defined according to the format
specified in this section, and are referred to as “built-in” DCPs. Built-in DCPs can be activated and viewed by any
SEMI E134-0305 © SEMI 2004, 2005 30
consumer with sufficient privilege (see Section 10) using the DataCollectionManager’s ActivatePlan and
GetPlanDefinition operations, respectively. Built-in DCPs cannot be deleted by any consumer.
11.1.2.2 DataCollectionPlan Attribute Definition Table
Table 41 DataCollectionPlan Attribute Definition
Attribute Name Definition Form
name Consumer-defined (or supplier-defined, in the
case of built-in DCPs) human-readable name
for the DCP.
Text.
id Consumer-defined (or supplier-defined, in the
case of built-in DCPs) unique identifier for the
DCP.
Text, unique across all DCP definitions on the
equipment, formatted according to the ISO
11578:1996 definition of UUID.
description Consumer-defined (or supplier-defined, in the
case of built-in DCPs) description of the
purpose of the DCP.
Text.
intervalInMinutes The preferred number of minutes for which the
equipment shall buffer all data described by the
plan.
Positive integer 0. See Section 11.1.2.3 for
further explanation.
isPersistent Whether or not the DCP, once activated, shall
remain activated across equipment shutdowns.
Boolean. See behavior defined in Section
12.1.5.
11.1.2.3 intervalInMinutes
11.1.2.3.1 If the value of this field is zero, events and exceptions contained in the plan shall be reported to the
consumer when they occur, and trace reports contained in the plan shall be reported according to their individual
buffer settings (see the description of the TraceRequest type in Section 11.1.5).
11.1.2.3.2 If the value of this field is greater than zero, upon activation of the DCP, any exceptions, events, or traces
defined in the plan that occur during this time span shall be buffered on the equipment in the order that they occur.
Buffered data shall be reported at the end of the interval, or when the equipment’s buffering capacity for the
currently active DCPs is reached, whichever is sooner. After each interval expires, the equipment shall begin
buffering new data for the next interval, again sending the results when the interval expires (or buffering capacity is
reached). Each result sent shall contain only the data collected during that interval. The equipment shall continue
this buffering/sending cycle as long as the DCP is active.
11.1.2.3.3 All data sent is formatted using the DataCollectionReport format described in Section 14.1.1.1.
11.1.2.4 DataCollectionPlan Association Definition Table
Table 42 DataCollectionPlan Association Definition
Association Role Name Definition Comments
eventRequests A set of events that the consumer is requesting to
be reported for this plan.
List of structured data, of type EventRequest,
described in Section 11.1.3.
exceptionRequests A set of exceptions that the consumer is
requesting to be reported for this plan.
List of structured data of type ExceptionRequest,
described in Section 11.1.4.
traceRequests A set of trace data collection activities that the
consumer is requesting to be reported for this
plan.
List of structured data of type TraceRequest,
described in Section 11.1.5.
SEMI E134-0305 © SEMI 2004, 2005 31
11.1.3 EventRequest — Identifies an event generated by a specific source that the consumer is requesting to be
reported when the DCP is activated. The equipment shall report only those events matching both the source and id
attributes specified in the EventRequst. The format for sending an event report is described in Section 14.1. The
equipment shall support multiple DCPs requesting the same event, with different sets of requested parameters. It
shall be an error to request the same event more than once in the same DCP (see Section 9.1.2.2.7).
11.1.3.1 EventRequest Attribute Definition Table
Table 43 EventRequest Attribute Definition
Attribute Name Definition Form
sourceId The source of the event. Text, formatted according to the convention used to identify an
event source. See limitations, Section 3.1.1.
eventId The identifier for the event. Text, formatted according to the convention used to identify a
specific event. See limitations, Section 3.1.1.
11.1.3.2 EventRequest Association Definition Table
Table 44 EventRequest Association Definition
Association Role Name Definition Comments
parameterRequests A set of parameters that the
consumer is requesting to be
reported when the requested event is
detected
Ordered list of structured data, of type ParameterRequest,
described in Section 11.1.5.6 . The order of the
ParameterRequests appearing in an EventRequest determines
the order in which those Parameter values will be reported in
the corresponding EventReport (see Section 14.1.3).
11.1.4 ExceptionRequest — Identifies an exception or class of exceptions that the consumer is requesting to be
reported when the DCP is activated. The format for sending an exception report is described in Section 14.1. The
equipment shall support multiple DCPs requesting the same exception criteria. It shall be an error to request the
same exception criteria more than once in the same DCP (see Section 9.1.2.2.8).
11.1.4.1 ExceptionRequest Attribute Definition Table
Table 45 ExceptionRequest Attribute Definition
Attribute Name Definition Form
sourceId The source of the exception. Text, formatted according to the convention used to identify an
exception source. See limitations, Section 3.1.1.
exceptionId The identifier of the exception. Text, formatted according to the convention used to uniquely
identify an exception. See limitations, Section 3.1.1.
severity The severity of the exception. Text, formatted according to the convention used to identify the
severity of an exception. Acceptable values, if any, are
supplier-defined.
11.1.4.2 sourceId — If this is the only non-empty attribute, then all exceptions from this source will be reported,
regardless of id or severity.
11.1.4.3 exceptionId — If this is the only non-empty attribute, then all exceptions with this id will be reported,
regardless of source or severity.
11.1.4.4 severity — If this is the only non-empty attribute, then all exceptions with this severity will be reported,
regardless of the source or id of the exception. Note that equipment suppliers are not required to define severity
classifications for exceptions. If severity classifications are not supported by the equipment supplier, any
ExceptionRequest containing a non-empty severity attribute shall be rejected as invalid (see Section 9.1.2.2.8). If
the equipment supplier does define severity classifications for exceptions, the ability to request exceptions based on
severity in a DCP shall be supported.