semi合集-English.pdf - 第3452页

SEMI E134-0305 © SEMI 2004, 2005 5 6.2.3.1 Open diamond adornm ents indicate t hat instances of th e target class may be shared am ong aggregate classes. Closed diam ond adornments indicat e that target instances belong …

100%1 / 7923
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’.
SEMI E134-0305 © SEMI 2004, 2005 6
6.2.6.4 Responder/Receiver — For RR semantics, identifies the entity that responds to the request, for FF
semantics, identifies the entity that receives the message. Can be either ‘consumer’ or ‘equipment’.
6.2.7 Operation Argument Definition Table — The table below provides an example of the tables used to list and
describe arguments for interface operations defined in this specification.
Table 4 Operation Argument Definitions
Argument Description Kind Form
See list below See list below
6.2.7.1 Argument — Specifies the name of the argument.
6.2.7.2 Kind — Specifies whether the argument is an ‘in’, ‘out’, or ‘error’ argument for the operation. ‘error’
arguments always function as ‘out’ arguments, but indicate that the operation did not complete successfully. All
possible errors that could be returned by an operation are listed in these tables. Unless otherwise indicated, only one
of the listed errors can be returned by an operation in a single invocation.
6.2.7.3 Form — Defines the data type of the argument. 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.
7 Background
7.1 Equipment Data Collection
7.1.1 Manufacturing equipment can be comprised of hundreds or thousands of components that interoperate in
order for the equipment to perform its intended function. The volume of information that such equipment can
produce, and the variation among equipment users in the data used for process control and other applications, makes
it impractical to send all equipment data off-tool all the time, or to agree on a fixed set of data to make available for
each equipment type. It is therefore important for the equipment to support the ability for consumers to dynamically
define the data that is of interest to them (see Figure 2).
Wafer Handling
Subsystem
Pump Subsystem
Mass Flow
Controller
…others…
Consumer
Equipment
Requested Data
Figure 2
Consumer Specifies What Data Should Be Sent Off-Tool
7.1.2 In addition to declaring interest in specific data that a consumer is interested in, different consumers have
different requirements for the acceptable latency with which data should be reported off-tool. For example, a
consumer that is monitoring a trace of several process variables in order to detect an excursion needs to have this
data available off-tool almost as quickly as the equipment can produce it (see Figure 3). A consumer that is
monitoring low-level sensor/actuator activity for later diagnosis prefers not to have all of this data transmitted as it is
produced, but buffered on the tool and transmitted at periodic intervals (see Figure 4).