semi合集-English.pdf - 第3511页
SEMI E134-0305 © SEMI 2004, 2005 64 RELATED INFORMATION 2 UML TERMINOLOGY NOTICE : This rel ated infor mation is not an official part of SEMI E125 and was derived from the wo rk of the originating committee. Th is relate…
SEMI E134-0305 © SEMI 2004, 2005 63
Create a DataCollectionPlan that includes at least one TraceRequest at the desired frequency. The
TraceRequest should include a ParameterRequest for each Parameter of interest from the previous step.
Inspect the E125 data from the equipment to determine the SEMI standard carrier management, control job,
process job, and substrate tracking events, exceptions, and available Parameters that provide key material and
processing status context.
In the DataCollectionPlan created earlier, include an EventRequest and ExceptionRequest for each context
event and exception of interest. For each EventRequest, include a ParameterRequest for each context data
variable available for that event.
Inspect the E125 data from the equipment to determine the supplier-defined events and data that communicate
what sub-recipes and which steps are executing on which components of the equipment, and any other supplier-
specific context data of significance to the purpose of the analysis application.
In the DataCollectionPlan created earlier, include an EventRequest and ExceptionRequest for each context
event and exception identified in the previous step. For each EventRequest, include a ParameterRequest for
each context data variable available for that event.
Submit the DCP to the equipment using the DataCollectionManager “DefinePlan” operation, and activate using
the “ActivatePlan” operation to begin receiving trace data and context events/exceptions.
R1-1.2.9 Once such a DCP has been activated, consumers can begin tracking the location of each substrate on the
equipment, so that their physical locations are always known. Since timestamps of all data are referenced to the
tool, synchronization of the events and data can be correlated correctly.
R1-1.2.10 Events from the equipment that inform what recipes are executing on which modules, and which step is
currently executing can be tracked and stored by the consumer, so it is always known which module is executing
which step in which recipe on which substrate.
R1-1.2.11 By tracking Control and Process Job events and data, a consumer can always determine to which job a
given substrate at a given location belongs.
R1-1.2.12 The consumer is responsible for managing the manufacturing context of each job, and so knows which
analysis needs to be performed on data from material from those jobs.
R1-1.2.13 Finally, because the consumer knows what the contents of the DCP are, it is also known which physical
equipment component produces each trace data variable. So, the data from a TraceReport can be correlated to a
physical equipment component, for which the consumer already knows the material located at that component, the
recipe executing on the component, the step the recipe is executing, the job the material belongs to, and the
manufacturing context for that job. Provided all of this information is provided correctly and in a timely fashion, a
consumer can always determine which analysis and/or control limits need to be applied to each TraceReport.
SEMI E134-0305 © SEMI 2004, 2005 64
RELATED INFORMATION 2
UML TERMINOLOGY
NOTICE: This related information is not an official part of SEMI E125 and was derived from the work of the
originating committee. This related information was approved for publication by full letter ballot procedures.
R2-1 Glossary
R2-1.1 In order to help with understanding terminology used in conjunction with object technology, this section
shares excerpts from the glossary of the OMG standard for UML — the predominant modeling notation.
R2-1.2 These definitions are taken from B.2 Glossary of Terms of version 1.4 of the OMG UML specification, 01-
09-67, available from http://www.omg.org/technology/documents/modeling_spec_catalog.htm.
R2-1.2.1 abstract class — a class that cannot be directly instantiated. Contrast: concrete class.
R2-1.2.2 aggregate [class] — a class that represents the “whole” in an aggregation (whole-part) relationship. See:
aggregation.
R2-1.2.3 aggregation — a special form of association that specifies a whole-part relationship between the aggregate
(whole) and a component part. See: composition.
R2-1.2.4 association — the semantic relationship between two or more classifiers that specifies connections among
their instances.
R2-1.2.5 attribute — a feature within a classifier that describes a range of values that instances of the classifier may
hold.
R2-1.2.6 cardinality — the number of elements in a set. Contrast: multiplicity.
R2-1.2.7 child — in a generalization relationship, the specialization of another element, the parent. See: subclass,
subtype. Contrast: parent.
R2-1.2.8 class — a description of a set of objects that share the same attributes, operations, methods, relationships,
and semantics. A class may use a set of interfaces to specify collections of operations it provides to its environment.
See: interface.
R2-1.2.9 class diagram — a diagram that shows a collection of declarative (static) model elements, such as classes,
types, and their contents and relationships.
R2-1.2.10 classification — the assignment of an object to a classifier. See: dynamic classification, multiple
classification, static classification.
R2-1.2.11 classifier — a mechanism that describes behavioral and structural features. Classifiers include
interfaces, classes, datatypes, and components.
R2-1.2.12 composition
— a form of aggregation which requires that a part instance be included in at most one
composite at a time, and that the composite object is responsible for the creation and destruction of the parts.
Composition may be recursive. Synonym: composite aggregation.
R2-1.2.13 concrete class — a class that can be directly instantiated. Contrast: abstract class.
R2-1.2.14 constraint — a semantic condition or restriction. Certain constraints are predefined in the UML, others
may be user defined. Constraints are one of three extensibility mechanisms in UML. See: tagged value, stereotype.
R2-1.2.15 dependency — a relationship between two modeling elements, in which a change to one modeling
element (the independent element) will affect the other modeling element (the dependent element).
R2-1.2.16 diagram — a graphical presentation of a collection of model elements, most often rendered as a
connected graph of arcs (relationships) and vertices (other model elements). UML supports the following diagrams:
class diagram, object diagram, use case diagram, sequence diagram, collaboration diagram, state diagram, activity
diagram, component diagram, and deployment diagram.
R2-1.2.17 element — an atomic constituent of a model.
SEMI E134-0305 © SEMI 2004, 2005 65
R2-1.2.18 feature — a property, like operation or attribute, which is encapsulated within a classifier, such as an
interface, a class, or a datatype.
R2-1.2.19 generalization — a taxonomic relationship between a more general element and a more specific element.
The more specific element is fully consistent with the more general element and contains additional information.
An instance of the more specific element may be used where the more general element is allowed. See:
inheritance.
R2-1.2.20 inheritance — the mechanism by which more specific elements incorporate structure and behavior of
more general elements related by behavior. See: generalization.
R2-1.2.21 instance — an entity that has unique identity, a set of operations that can be applied to it, and state that
stores the effects of the operations. See: object.
R2-1.2.22 interface — a named set of operations that characterize the behavior of an element.
R2-1.2.23 interface inheritance — the inheritance of the interface of a more general element. Does not include
inheritance of the implementation. Contrast: implementation inheritance.
R2-1.2.24 message — a specification of the conveyance of information from one instance to another, with the
expectation that activity will ensue. A message may specify the raising of a signal or the call of an operation.
R2-1.2.25 method — the implementation of an operation. It specifies the algorithm or procedure associated with an
operation.
R2-1.2.26 model [MOF] — an abstraction of a physical system with a certain purpose. See: physical system.
Usage note: In the context of the MOF specification, which describes a meta-metamodel, for brevity the
metametamodel is frequently referred to as simply the model.
R2-1.2.27 multiple inheritance — a semantic variation of generalization in which a type may have more than one
supertype. Contrast: single inheritance.
R2-1.2.28 multiplicity — a specification of the range of allowable cardinalities that a set may assume. Multiplicity
specifications may be given for roles within associations, parts within composites, repetitions, and other purposes.
Essentially a multiplicity is a (possibly infinite) subset of the non-negative integers. Contrast: cardinality.
R2-1.2.29 object — an entity with a well-defined boundary and identity that encapsulates state and behavior. State
is represented by attributes and relationships, behavior is represented by operations, methods, and state machines.
An object is an instance of a class. See: class, instance.
R2-1.2.30 object diagram — a diagram that encompasses objects and their relationships at a point in time. An
object diagram may be considered a special case of a class diagram or a collaboration diagram. See:
class diagram,
collaboration diagram.
R2-1.2.31 operation — a service that can be requested from an object to effect behavior. An operation has a
signature, which may restrict the actual parameters that are possible.
R2-1.2.32 package — a general purpose mechanism for organizing elements into groups. Packages may be nested
within other packages.
R2-1.2.33 parent — in a generalization relationship, the generalization of another element, the child. See:
subclass, subtype. Contrast: child.
R2-1.2.34 qualifier — an association attribute or tuple of attributes whose values partition the set of objects related
to an object across an association.
R2-1.2.35 relationship — a semantic connection among model elements. Examples of relationships include
associations and generalizations.
R2-1.2.36 role — the named specific behavior of an entity participating in a particular context. A role may be static
(for example, an association end) or dynamic (for example, a collaboration role).
R2-1.2.37 single inheritance — a semantic variation of generalization in which a type may have only one
supertype. Synonym: multiple inheritance [OMA]. Contrast: multiple inheritance.