semi合集-English.pdf - 第3451页

SEMI E134-0305 © SEMI 2004, 2005 4 6 Conventions 6.1 Terms 6.1.1 Class, Data Type, Stereoty pe Name — This specification uses the terms “class”, “data type”, “type”, or the class stereotype name interchangeably to re fer…

100%1 / 7923
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.
SEMI E134-0305 © SEMI 2004, 2005 5
6.2.3.1 Open diamond adornments indicate that instances of the target class may be shared among aggregate
classes. Closed diamond adornments indicate that target instances belong to at most one composite class. The part-
whole semantics of the aggregation/composition symbol is not significant in this specification. See the UML 1.4
specification, Sections 3.43.2.5 and 3.48 for further information.
6.2.3.2 Some diagrams use the UML “ordered” or “XOR” constraints where applicable. An “ordered” constraint on
an association indicates that the order in which the target instances appear in the aggregation is semantically
significant, and is described in the supporting text of the diagram. See the UML 1.4 specification, Section 3.43.2.2
for further information.
6.2.3.3 An “XOR” constraint indicates that only one of many possible associations can be instantiated at any one
time for a given instance of the association class. See the UML 1.4 specification, Section 3.42.5.1 for further
information.
6.2.4 Association Tables — The table below provides an example of the tables used to list and describe associations
between classes defined in this specification.
Table 1 Association Table Format
Association
Role Name
Definition Comments
6.2.4.1 Association Role Name — The name of the association role being specified.
6.2.4.2 Definition — Describes the function or purpose of the association.
6.2.4.3 Comments — Any additional comments or notes regarding the association.
6.2.5 Attribute Tables — The table below provides an example of the tables used to list and describe attributes of
classes defined in this specification.
Table 2 Attribute Table Format
Attribute Name Definition Form
See list below
6.2.5.1 Form — Defines the data type of the attribute. The terms used to describe data types in this column are
defined in the SEMI Compilation of Terms, or are included as part of the specification. Refer to the compilation of
terms for the definition of SEMI type name meanings.
6.2.6 Operation Definition Tables — The table below provides an example of the tables used to list and describe the
interface operations defined in this specification.
Table 3 Operation Definition
Operation Description Type Requestor/Sender Responder/Receiver
See list below
6.2.6.1 Operation — Specifies the name of the operation.
6.2.6.2 Type — Specifies the messaging semantics of the operation. Only Request-Reply (RR) and Fire-and-Forget
(FF) semantics are used in this specification. Request-Reply messages are messages that involve an initiator and a
receiver. In a Request-Reply exchange, the initiator sends a single request message to the receiver, and the receiver
sends a single reply message to that request back to the initiator. Fire-and-Forget messages are messages that
involve a sender and a receiver. In a Fire-and-Forget exchange, the sender sends a single message to the receiver,
with no associated response.
6.2.6.3 Requestor/Sender — For RR semantics, identifies the entity that makes the request, for FF semantics,
identifies the entity that sends the message. Can be either ‘consumer’ or ‘equipment’.