semi合集-English.pdf - 第2758页
SEMI E98-1102 © SEMI 2000, 2002 23 10.4.8.1.2 A typical kind of AbstractE quipmentElement t hat the user m ay want to add is an “add- on sensor”, a SensorActuato r Device on a S ensor/Actuator Network. I f the Equipment …

SEMI E98-1102 © SEMI 2000, 2002 22
10.4.4.7 SubstrateLocation Object — The SubstrateLocation object is defined in SEMI E90 (STS). STS defines
SubstID as an attribute of SubstrateLocation. Note this is identical to MaterialID in the general case for
MaterialLocation.
10.4.5 AbstractEquipmentSubsystem Requirements
10.4.5.1 AbstractEquipmentSubsystems may or may not be able to hold material.
10.4.5.2 The AbstractEquipmentSubsystem owns all of the MaterialLocations that it provides or that are provided
by one of its components. Similarly, it owns all of the Material at those MaterialLocations.
10.4.6 AbstractEquipmentSubsystem Type — Figure 13 shows the diagram for the AbstractEquipmentSubsystem
object.
Abstract Equipment
Subsystem
MaterialSummary
AddElement
RemoveElement
Figure 13
AbstractEquipmentSubsystem Object Type
10.4.7 AbstractEquipmentSubsystem Attributes
10.4.7.1 Table 8 defines the attributes of the AbstractEquipmentSubsystem.
Table 8 AbstractEquipmentSubsystem Attribute Definition
Attribute Name Definition Access Reqd Form
ObjType Object type RO Y Text=“AbstractEqpSubsystem”
ObjID Object identifier RO Y Text
MaterialSummary List of specifications of material
capacity and current status for
each type of material.
RO N List of
structure composed of
MaterialType, MaterialCapacity, and MaterialCount.
10.4.7.2 Table 9 defines individual elements of AbstractEquipmentSubsystem attributes.
Table 9 Definition of Elements of MaterialSummary Attribute
Element Name Definition Access Reqd Form
MaterialCapacity Number of units of material that can be held at one
time.
RO Y Unsigned integer.
MaterialCount Current number of units of material present. RO Y Unsigned integer.
MaterialType Specifies the type of material held. RO Y Text. Conforms to SEMI E5.
10.4.8 AbstractEquipmentSubsystem Services
10.4.8.1 Add Element
10.4.8.1.1 The user may be able to instruct the equipment to add a specific type of AbstractEquipmentElement. The
supplier may restrict this service to specific AbstractEquipmentElement subtypes, both in destination (the
AbstractEquipmentElement accepting the addition) and in the added element. This is an optional service.

SEMI E98-1102 © SEMI 2000, 2002 23
10.4.8.1.2 A typical kind of AbstractEquipmentElement that the user may want to add is an “add-on sensor”, a
SensorActuatorDevice on a Sensor/Actuator Network. If the Equipment knows the properties, it is possible for it to
read an added I/O device and to reference it within recipes.
10.4.8.2 Remove Element — The user may instruct the equipment to remove an AbstractEquipmentElement that
was added earlier. This service is required wherever the Add Element service is supported.
10.4.9 EquipmentSubsystem Object
10.4.9.1 The EquipmentSubsystem is a concrete subtype of AbstractEquipmentSubsystem. It inherits all of the
attributes, state models, and services of the AbstractEquipmentSubsystem and in addition defines the rules for
aggregation. These rules are illustrated in Figure 14.
M + N >= 1
Equipment
IODevice
Equipment
Subsystem
M
N
Figure 14
EquipmentSubsystem Aggregation
10.4.9.2 As shown in Figure 14, the EquipmentSubsystem may be made up of other, smaller EquipmentSubsystems
and/or EquipmentIODevices. It is required to have at least one of these two components.
Table 10 EquipmentSubsystem Attribute Definition
Attribute Name Definition Access Reqd Form
ObjType Object type RO Y Text = “EqpSubsystem”
ObjID Object identifier RO Y Text.
10.5 AbstractEquipmentModule Object
Equipment
Module
Recipe
Executor
Process
Matching
Abstract
Equipment
Module
Equipment
Figure 15
AbstractEquipmentModule Types

SEMI E98-1102 © SEMI 2000, 2002 24
10.5.1 As shown in Figure 15, an AbstractEquipment-
Module is a type of AbstractEquipmentSubsystem that
represents a higher level of complexity and is of greater
importance to the factory. It is mainly intended to
represent process modules but may be used for other
major intelligent subsystems capable of supporting the
requirements for the AbstractEquipmentModule. It may
be possible in some cases for the physical module to
operate independently from the equipment.
10.5.2 The AbstractEquipmentModule has two
subtypes, Equipment and EquipmentModule.
10.5.3 ProcessMatching
10.5.3.1 ProcessMatching provides one or more
mechanisms for managing process differences between
two or more identically configured subsystems of the
same type to ensure that a generic recipe run on both
subsystems will achieve the same process result.
ProcessMatching may be either internal or external or
both.
10.5.3.2 An example of an external method would be
through provision of a ProcessMatching object that
allows a user to manipulate offsets to process
parameters. This can be done through setting parameter
offsets for each subsystem so that, within specified
constraints, all subsystems of the same type give the
same process results. More sophisticated systems may
use algorithms to determine process offsets based on
mathematical models and module history.
10.5.3.3 As a simple example of process matching,
three different individual hotplates may be matched for
the temperature range 225–275° C by modifying their
temperature offset by 1° C, 1.75° C, and –2.1° C
respectively. This approach is illustrated in Figure 16.
10.5.3.4 The equipment supplier is responsible for
determining the set of parameters to which offsets may
be applied as well as the range of values that are valid.
ProcessMatching
- Name
- Description
- ParameterList
- ProcessGoal
1+
Parameter
Maximum
Minimum
Name
Offset
Units
Figure 16
ProcessMatching and Parameter Objects