semi合集-English.pdf - 第2975页

SEMI E120-0705 © SEMI 2003, 2005 11 Nameab le Extension extensions 0..* 1 targe t Figure 7 Extensio n Class Table 5 A ttributes of Extension Attribute Name Definition Access Reqd Form <<none defined>> 8.5.3.4…

100%1 / 7923
SEMI E120-0705 © SEMI 2003, 2005 10
ModuleEquipment
+processName:string
+processType:string
+recipeType:string
ExecutionElement
EquipmentElement
Figure 6
ExecutionElement Class
Table 4 Attributes of ExecutionElement
Attribute Name Definition Access Reqd Form
processName Describes the processing that occurs at this ExecutionElement (e.g.,
“coat”, “develop”, “bake”, etc.).
RO Y String
processType Categorizes the primary processing function of this ExecutionElement as
an enumerated value chosen from the values: Measurement, Process,
Storage, or Transport. See ¶8.5.3.3.1 for description of processType
values.
RO Y Enumeration
recipeType Instances of ExecutionElement having identical strings for recipeType are
capable of executing the same set of recipes (e.g. processing
instructions). Note that identical results are not guaranteed.
RO Y String
8.5.3.3.1 The definition of processType lists four enumerated values. These are described as follows:
Measurement — Refers to Equipment or Modules whose intended function is to measure or inspect the product
and report results.
Process — Refers to Equipment or Modules whose intended function is to process product by adding value to
the product.
Storage — Refers to Equipment or Modules whose intended function is primarily to provide storage, either
short-term or long-term, for carriers (e.g. stockers).
Transport — Refers to Equipment or Modules whose intended function is primarily to move material from one
location to another. Transport equipment may also provide short-term storage for material.
8.5.3.4 Extension — This abstract class provides the ability for other SEMI standards and implementers to extend
the CEM. Extension has no superclass and no attributes (see Table 5). It is associated with Nameable (see Figure
9). This association is navigable in both directions so that an Extension can identify the class that it modifies and a
Nameable knows its Extensions.
8.5.3.4.1 Extension is modeled to allow extension of any Nameable. However, in practice, only concrete objects
that inherit from Nameable shall have extensions.
8.5.3.4.2 As an abstract class, Extension must have a concrete subclass in order to be useful. The definition of
subclasses of Extension is left to the implementer and/or other standards to define as extensions to the CEM. See
¶6.3 for a discussion of how the Extension class may be used to extend the Common Equipment Model.
SEMI E120-0705 © SEMI 2003, 2005 11
Nameable
Extension
extensions
0..*
1
target
Figure 7
Extension Class
Table 5 Attributes of Extension
Attribute Name Definition Access Reqd Form
<<none defined>>
8.5.3.4.3 Since each class in the CEM inherits from Nameable, this extension method applies to the entire CEM.
However, for ease of management, this specification limits the extensions. Extensions shall be applied to concrete
CEM classes only.
8.5.3.4.4 Any number of subclasses of Extension may be created and thus be available as extensions of CEM
classes. No extension shall conflict with or override any feature of the CEM.
So, for example, no CEM defined
attributes may be redefined as a different type.
8.5.4 Concrete Classes
8.5.4.1 Equipment — This class models the equipment as a whole. Equipment is a subclass of ExecutionElement
(see Figure 10). An Equipment is an aggregate of Modules, Subsystems, and IODevices. It must contain a total of at
least one of these components, but may contain zero or more of each. An Equipment that can communicate
information about or act on behalf of other Equipment will also model associations with these Equipment
2
.
Equipment defines no additional attributes defined in the Common Equipment Model (see Table 6).
8.5.4.1.1 Figure 10 shows that a Module or Subsystem may belong to more than one Equipment. The case where
these components can be shared by multiple Equipment is unusual. An example of this would be where an in-line
metrology tool is shared. In most cases, a Module or Subsystem will belong to zero or one Equipment.
0..*
0..1
+equipment
IODeviceSubsystem Module
0..*
0..*
0..*
+ioDevices
+subsystems
AbstractModule
At least one of
Subsystem, Module, or
IODevice must exist.
0..*
0..10..*
+modules
Equipment
MaterialLocation
0..*
+materialLocations
0..1
EquipmentElement
Figure 8
Equipment Class
2 This specification does not attempt to encourage or endorse any particular approach to structuring a single equipment or equipment acting in
tandem. It attempts only to provide a means for representing any structure that could reasonably be expected to exist.
SEMI E120-0705 © SEMI 2003, 2005 12
Table 6 Attributes of Equipment
Attribute Name Definition Access Reqd Form
<<none defined>>
8.5.4.2 Module — This class models major subsystems of the equipment, such as process chambers. Module is a
subclass of ExecutionElement (see Figure 11).
8.5.4.2.1 A Module is capable of having (zero or more) MaterialLocations and is capable of processing material. A
Module or one of its aggregated Subsystem or Module objects must contain at least one MaterialLocation.
8.5.4.2.2 A Module must be a component part of Equipment or another Module and may be shared by multiples of
these. It may also be an aggregation of Subsystem, IODevice, and/or other Module instances (zero or more each).
8.5.4.2.3 Module has no additional attributes defined in the Common Equipment Model (see Table 7).
IODeviceSubsystem
Equipment
+modules
0..*
0..*
0..*
0..*
+ioDevices
+modules
+subsystems
ExecutionElement
0..*
0..*
0..*
0..*
MaterialLocation
0..*
+materialLocations
Module
0..1
Figure 9
Module Class
Table 7 Attributes of Module
Attribute Name Definition Access Reqd Form
<<none defined>>
8.5.4.3 Subsystem — This class models subsystem and subassembly components of the equipment (see Figure 12).
Subsystem is a subclass of EquipmentElement.
8.5.4.3.1 A Subsystem may be capable of having (zero or more) MaterialLocations, but is not capable of processing
material.
8.5.4.3.2 A Subsystem must be a component part of Equipment, Module, or another Subsystem and may be shared
by multiples of these. It may also be an aggregation of Subsystem, or IODevice instances (zero or more each).
8.5.4.3.3 Subsystem has no additional attributes defined in the Common Equipment Model (see Table 8).