semi合集-English.pdf - 第3097页

SEMI E125-0305 © SEMI 2003, 2005 5 Table 2 A ssociation Table Format Association Role Name Definition Comments 6.1.4.1 Association Role Na me — The nam e of the association role being specified. 6.1.4.2 Definitio n — Des…

100%1 / 7923
SEMI E125-0305 © SEMI 2003, 2005 4
6 Conventions
6.1 Document and Notation Conventions
6.1.1 Unified Modeling Language (UML) — This specification uses the UML conventions for representing all
class, state, object, and sequence diagrams. Refer to the UML specification for a detailed description of these
conventions.
6.1.2 Attribute Tables — The table below provides an example of the tables used to list and describe attributes of
classes defined in this specification.
Table 1 Attribute Table Format
Attribute Name Definition Required Form
Y or N See list below
6.1.2.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.1.3 UML Associations — The mechanism used for representing 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.
Class2Class1
1 roleName10..*
1..*
roleName2
1
{XOR}
Class3
1
roleName3 1
1
roleName4 1
Figure 1
Association Notation
6.1.3.1 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. See the UML 1.4 specification, Section 3.43 for details. All role names are public by
default; therefore the visibility symbols are not used.
6.1.3.1.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.1.3.1.2 Some diagrams use the UML “XOR” constraint where applicable. 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.1.4 Association Tables — The table below provides an example of the tables used to list and describe associations
between classes defined in this specification.
SEMI E125-0305 © SEMI 2003, 2005 5
Table 2 Association Table Format
Association Role Name Definition Comments
6.1.4.1 Association Role Name — The name of the association role being specified.
6.1.4.2 Definition — Describes the function or purpose of the association.
6.1.4.3 Comments — Any additional comments or notes regarding the association.
6.1.5 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
See list below
6.1.5.1 Operation — Specifies the name of the operation.
6.1.5.2 Type — Specifies the messaging semantics of the operation. Only Request-Reply (RR) 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.1.6 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.1.6.1 Argument — Specifies the name of the argument.
6.1.6.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.
6.1.6.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.
6.2 Terms
6.2.1 Class, type — This specification uses the terms “class” and “type”, interchangeably to refer to a UML class.
7 Background
7.1 Motivation
7.1.1 This specification is designed to help address the problem of integrating semiconductor equipment from a
variety of suppliers into an automated factory environment, and to provide a standard mechanism for describing
information and data that the equipment can provide for a wide variety of uses. See Related Information 1 for an
overview of some example use cases.
7.1.2 This specification defines the information that is needed to communicate essential features of the equipment
to software applications, and provides extensibility features to allow suppliers to communicate information unique to
their equipment or that may not be specified in a SEMI standard.
SEMI E125-0305 © SEMI 2003, 2005 6
7.1.3 Equipment metadata is designed to be useful to applications that provide an interface to human end users for
the purposes of understanding and browsing equipment configuration, available data items, events, exceptions, etc.
In many cases, these users will be referring to equipment metadata so they can perform data collection for a variety
of objectives (diagnostics, troubleshooting, process control, etc.).
7.1.4 Equipment metadata is also designed to be useful to applications written to take advantage of standardized
state models and other data so that discovery and usage of this information can be automated, without requiring
human intervention. Diagnostics, health monitoring, or other supplier-provided applications that understand the
details of specific equipment types, for example, can also discover and use common equipment-specific
configuration and data without requiring manual assistance.
8 Overview
8.1 Equipment Metadata Organization
8.1.1 Figure 2 shows the concepts that are included in this specification and their relationship to the SEMI E120
Common Equipment Model. A brief description of the purpose of each metadata concept is provided in this section
only as an overview. For the detailed specification of the corresponding classes, refer to Section 10.
Figure 2
Organization of Metadata Concept
8.1.2 Equipment Node Description
8.1.2.1 This specification defines classes that provide a way to associate events, exceptions, parameters, and SEMI
E39 ObjTypes with any node in the physical equipment structure. SEMI E120 defines the classes that are used to
describe the physical equipment structure; this specification defines the classes that link E120 equipment nodes with
the events, exceptions, parameters, and ObjTypes that they produce. Equipment node description classes are defined
in Section 10.3 .
8.1.3 Parameters
8.1.3.1 This specification defines classes that can be used to describe any variables that are provided by the
equipment, and refers to all such variables as “Parameters”. Parameters can be used to model any concept that can
be represented as a data type. For example, the SEMI E30 concepts of equipment constants, data variables, and
status variables can all be represented by a parameter. Any type of data that the equipment can produce (for
example, measurement results on metrology equipment) can be represented by a Parameter. Parameters can only be