semi合集-English.pdf - 第2979页

SEMI E120-0705 © SEMI 2003, 2005 15 Table 11 A ttributes of SoftwareModule Attribute Name Definition Required Form name The name of the Soft wareModule. Y String supplier The name of the company that created the Software…

100%1 / 7923
SEMI E120-0705 © SEMI 2003, 2005 14
8.5.4.5 MaterialLocation — This concrete class models the ability of certain equipment components to hold
material. MaterialLocation is a subclass of Nameable. The attributes of MaterialLocation class are defined in Table
10.
8.5.4.5.1 A MaterialLocation is exclusively related to a single Equipment, Module, or Subsystem in a composite
aggregation (see Figure 14). Each Equipment, Module, and Subsystem may have zero or more MaterialLocations.
Equipment, Modules, and Subsystems may also have indirect access to MaterialLocations if they aggregate a
component that has a MaterialLocation. So, for instance, a Module may not have a MaterialLocation, but may
contain a Subsystem with a MaterialLocation.
materialType:enumeration
MaterialLocation
+materialLocations
0..*
Nameable
SubsystemEquipment Module
+materialLocations
0..*
+materialLocations
0..*
A MaterialLocation is
included in only one o f
these compositions
0..1 0.. 1 0.. 1
Figure 12
MaterialLocation Class
Table 10 Attributes of MaterialLocation
Attribute Name Definition Access Reqd Form
materialType Type of material held. Enumeration value is one of the following:
Carrier, Substrate, ProcessDurable
RO Y Enumeration
8.5.4.6 SoftwareModule — This concrete class is used to describe the existence and version of equipment system
software that is in use on the equipment and on equipment components. Such software might be supplied by the
equipment manufacturer or by third parties. It includes any software that may be changed without affecting the
identity of the hardware. This would cover software stored on disk drives, flash memory, eeproms, and other
memory devices. This class allows the factory host to track changes in the software. See ¶8.5.3.2
EquipmentElement for the definition of the modelRevision attribute that tracks changes in hardware. Tracking
hardware and software revisions together allows better detection of changes in the equipment capability.
8.5.4.6.1 The SoftwareModule class is a component of EquipmentElement in a composite aggregation (see Figure
15). It has four attributes: name, supplier, description, and version (see Table 11). In the case where a
SoftwareModule affects multiple EquipmentElements, each would contain its own separate SoftwareModule
describing the same software.
+name:string
+supplier:string
+description:string
+version:string
SoftwareModule
EquipmentElement
0..*
softwareModules
Figure 13
SoftwareModule Class
SEMI E120-0705 © SEMI 2003, 2005 15
Table 11 Attributes of SoftwareModule
Attribute Name Definition Required Form
name The name of the SoftwareModule. Y String
supplier The name of the company that created the SoftwareModule. Where
this information cannot be determined or configured, it shall have the
value “unknown”.
Y String
description A description of the function or purpose of the SoftwareModule. Y String
version The version number of the SoftwareModule. It should be formatted
according to the version numbering convention of the company that
produced the SoftwareModule.
Y String
9 Positional Referencing Of Nameable Objects
9.1 Introduction
9.1.1 The E120 specification provides fixed referencing of all Nameable objects by means of the uid attribute. The
uid is fixed to a specific hardware entity. Consider a massflow controller that fails and is swapped out with one of
the same kind. It is expected that the name attribute of that massflow controller would become the same as the old
one, but it is required that the uid be different. Thus, the name is distinctively a “positional reference” that identifies
a place or position in the hierarchy.
9.1.2 This section defines a positional reference that is unique within the equipment. This “Locator” value is based
on the name attribute of Nameable. It can be used in communications to the equipment to uniquely identify a
Nameable object in that equipment.
9.1.3 If the equipment provides a positional reference for an equipment component, the Locator form, as defined in
this section, shall be used.
9.1.4 There are some situations where a positional reference to an equipment component is more useful than the
fixed reference that uid provides. For example, a data collection plan might indicate that during processing, the
reading from a massflow controller (one kind of Nameable) is to be recorded. At some point, the massflow
controller is replaced. If the reference in the specification is to the uid, then the data collection plan no longer
works. In a worse case, two identical massflow controllers are removed from similar process modules for
maintenance and then replaced on the opposite modules. In this case, the uid reference would yield data from the
wrong process module. If a positional reference were used, then the data collection plan would always collect
readings from the massflow controller on the specified process module.
9.2 Constructing A Locator
9.2.1 Values for the Locator string are derived by starting with the name attribute of the root Nameable (usually an
Equipment) in the hierarchy followed by the ‘/’ character. This is followed by the names of any objects between the
root and target (each name separated by the ‘/’ character). Finally, the name of the target is added. A shorthand
notation for this pattern is: “root/aggregate/aggregate/aggregate/target”. Example values for Locator are illustrated
by the block diagram in Figure 14.
SEMI E120-0705 © SEMI 2003, 2005 16
Object5 (Equipment)
name=Track
Locator=Track
Object6 (Subsystem)
name=Port-1
Locator=Track/Port-1
Object8 (Subsystem)
name=Power
Locator=Track/Port-1/Power
Object7 (Subsystem)
name=Port-2
Locator=Track/Port-2
Object9 (Subsystem)
name=Power
Locator=Track/Port-2/Power
Figure 14
Example: Equipment Hierarchy
9.2.2 In the case where an object is shared, there may be more than one Locator that will resolve to that object. The
block diagram in Figure 15 gives an example of the Locators that might result. Notice that Object8 is shared by
Object6 and Object7. This means that it can be referenced by two different but equally valid Locator values as
shown in the diagram. For Nameable instances with more than one possible Locator value, any valid Locator
construct will resolve to that object.
Object5 (Equipment)
name=Track
Locator=Track
Object6 (Subsystem)
name=Port-1
Locator=Track/Port-1
Object8 (Subsystem)
name=Power-1
Locator=Track/Port-1/Power-1
=Track/Port-2/Power-1
Object7 (Subsystem)
name=Port-2
Locator=Track/Port-2
Object9 (Subsystem)
name=Power-2
Locator=Track/Port-2/Power-2
Figure 15
Example: Equipment Hierarchy With Shared Object
9.2.3 Note that the Locator value is valuable as a reference to a Nameable. However, that value is not available
from the Nameable as an attribute. The Locator can be built independently and used when only the names are
known or when the position in the hierarchy is more important than the identity of the equipment component being
referenced.