semi合集-English.pdf - 第3450页

SEMI E134-0305 © SEMI 2004, 2005 3 4 Referenced Standards 4.1 SEM I Standard s SEMI E30 — Generic Model for Com munications and Co ntrol of M anufacturi ng Equipment (GEM ) SEMI E40 — Standard for Processing M anagem ent…

100%1 / 7923
SEMI E134-0305 © SEMI 2004, 2005 2
15.2 DCPConsumer.................................................................................................................................................56
16 Requirements for Compliance ................................................................................................................................60
1 Purpose
1.1 This specification describes a method for data acquisition consumers to request process and operational data
from equipment to be communicated in an automated fashion by the equipment, or in an ad-hoc request from the
consumer. It includes a mechanism for organizing related data into groups to make it more straightforward for
enabling or disabling a large number of data sources, and to allow consumers to organize related data into groups
according to their purpose.
2 Scope
2.1 In-scope
2.1.1 This specification provides a means to acquire event, exception, and trace data from semiconductor equipment
through the use of a named data collection plan. This specification defines what form a data collection plan takes,
the meaning of its contents, and an interface for managing them that is to be supported by the equipment.
2.1.2 This specification defines the behavior associated with the execution of data collection plans in the form of
finite state machines. The formats for data produced as a result of executing a data collection plan are also defined,
as is the interface that must be supported by consumers of data collection plan output.
2.1.3 This specification defines a way for the equipment to notify consumers when the combination of activities on
the equipment, including data acquisition, are causing the equipment to perform below supplier-defined criteria.
2.1.4 This specification defines a way for consumers to make ad-hoc on-demand requests for data from the
equipment, outside of a data collection plan.
2.2 Out-of-scope
NOTICE: This standard does not purport to address safety issues, if any, associated with its use. It is the
responsibility of the users of this standard to establish appropriate safety and health practices and determine the
applicability of regulatory or other limitations prior to use.
3 Limitations
3.1 Abstract Model
3.1.1 This specification does not define a convention for naming or identifying sources, parameters, events, or
exceptions. This document assumes that all such entities can be identified separately and represented as text. Such
conventions shall be fully specified by any implementation mapping of this specification.
3.1.2 This specification does not define the mechanism used for identifying or authenticating consumers or
enforcing privileges. It assumes that consumers can be uniquely identified by a text value, and that the equipment is
capable of enforcing the standard privileges defined in this document. Such mechanisms shall be fully specified by
any implementation mapping of this specification.
3.1.3 This specification does not define the mechanism used for determining how to locate consumers that are to
receive the events defined by this specification. It assumes that the equipment has established a communications
context with any consumers that can submit requests and has provided any context necessary to send events to those
consumers. Such mechanisms shall be fully specified by any implementation mapping of this specification.
3.1.4 This specification does not define any algorithms or heuristics to use for detecting degrading equipment
operational performance. Such techniques are specific to the equipment’s internal hardware and software
architecture and will very likely be unique to each class and/or model of equipment. It assumes that it is possible to
detect such conditions and to identify which systems comprising the equipment are affected.
3.1.5 This specification is an abstract model only. Adjunct specifications must be developed to map this
specification to an implementation technology.
SEMI E134-0305 © SEMI 2004, 2005 3
4 Referenced Standards
4.1 SEMI Standards
SEMI E30 — Generic Model for Communications and Control of Manufacturing Equipment (GEM)
SEMI E40 — Standard for Processing Management
SEMI E94 — Provisional Specification for Control Job Management
4.2 Non-SEMI Standards
International Standards Organization (ISO) 11578:1996
1
— Information technology Open Systems Interconnection
– Remote Procedure Call definition of UUID
ISO 8601
2
— Representations of dates and times, 1988-06-15
ISO 8601 Draft Revision — Representations of dates and times, draft revision, 2000
Unified Modeling Language (UML) Specification, Version 1.4, OMG Specification 01-09-67
3
NOTICE: Unless otherwise indicated, all documents cited shall be the latest published versions.
5 Terminology
5.1 Abbreviations and Acronyms
5.1.1 Descriptions of many of the abbreviations and acronyms used in this specification may be found in the SEMI
Compilation of Terms, available on the SEMI web site, http://www.semi.org/. In most cases, these terms are not
included in this section.
5.1.2 DCP — Data Collection Plan
5.1.3 UML — Unified Modeling Language
5.2 Definitions
5.2.1 Definitions or descriptions of many of the terms used in this specification may be found in the SEMI
Compilation of Terms, available on the SEMI web site, http://www.semi.org/. In most cases, these terms are not
included in this section.
5.2.2 Related Information, Section 1, contains useful definitions of UML terms taken directly from the UML
standard. UML terms used in this document conform to these definitions. Please refer to this Section as needed.
5.2.3 collection result — the set of data values obtained during trace data collection.
5.2.4 collection frequency — the rate at which the collection of one or more data values is performed. This is not
the same as the frequency with which the equipment internally samples these data from its components.
5.2.5 data source — a physical or logical entity associated with the equipment that is capable of providing data
values independently of other equipment entities.
5.2.6 event source — a physical or logical entity associated with the equipment that is capable of generating events
independently of other equipment entities
5.2.7 exception source — a physical or logical entity associated with the equipment that is capable of generating
exceptions independently of other equipment entities
5.2.8 parameter source — a physical or logical entity associated with the equipment that is capable of providing
parameters independently of other sources. This term may be used interchangeably with ‘data source’.
5.2.9 source id — a name or other token that uniquely identifies a specific origin or producer of information from
among possible sources.
1 http://www.iso.ch/cate/d2229.html
2 http://www.iso.ch/cate/d26780.html
3 http://www.omg.org/technology/documents/modeling_spec_catalog.htm
SEMI E134-0305 © SEMI 2004, 2005 4
6 Conventions
6.1 Terms
6.1.1 Class, Data Type, Stereotype Name — This specification uses the terms “class”, “data type”, “type”, or the
class stereotype name interchangeably to refer to a UML class.
6.1.2 Consumer — This specification uses the term “consumer” to refer to any software entity that uses the
DataCollectionManager interface to manage data collection on the equipment.
6.1.3 Built-in DCP — This specification uses the term “built-in” DCP to refer to pre-defined DCPs that are
provided with the equipment. Built-in DCPs can be activated by any consumer, but can not be changed or deleted
by any consumer. See Section 11.1.2.1 for details.
6.1.4 Reporting, Buffering, Sending — This specification uses the term “reporting” to refer to the act of collecting
event, exception, or trace data values to later be sent to a consumer. The term “buffering” is used to refer to the act
of storing a data report on the equipment for some period of time before sending to a consumer. The term “sending”
is used to refer to the act of sending a report to a consumer.
6.2 Notation
6.2.1 Unified Modeling Language Notation — All class and sequence diagrams in this specification make use of the
Unified Modeling Language notation.
6.2.1.1 UML Stereotypes — This specification uses the following stereotypes in class diagrams:
<<privilege>> — Classes with this stereotype identify an abstract privilege concept that grants permission to a
consumer to perform an activity or operation.
<<interface>> — Classes with this stereotype define a collection of operations and their semantics. It is the
responsibility of the equipment and its consumers, where specified, to provide implementations of these classes.
<<enumeration>> — Classes with this stereotype identify data types that have a finite set of discrete values that
can be assumed by instances of the class.
6.2.2 UML Associations — The mechanism used for realizing UML associations between classes is implementation
dependent. This document is abstract in nature, and does not specify or imply any such mechanism. Any adjunct
standard that provides an implementation of this specification must include a description of the mechanism used for
representing the UML associations shown in this document.
Class2
Class1
1
roleName10..*
1..*
roleName2
1
{XOR}
{ordered}
Class3
1
roleName3 1
1
roleName4 1
Figure 1
Association Notation
6.2.3 Association Notation — This document uses the UML aggregation diamond adornment, role names, end
multiplicities, and navigability in all class diagrams specifying associations. Unadorned associations are not used,
for economy of notation. All role names are public by default, therefore the visibility symbols are not used. See the
UML 1.4 specification, Section 3.43 for details.