semi合集-English.pdf - 第2749页
SEMI E98-1102 © SEMI 2000, 2002 14 9.5 OBEM Objec t Requirements — By definit ion, subtypes of o bjects inher it the properties (attributes, services, and relationshi ps) of their supertypes. I n some cases, properties o…
SEMI E98-1102 © SEMI 2000, 2002 13
these elements may be of interest to the factory. In particular, process modules, which are intelligent and may be
independently operable, are very interesting to the factory, since these are the units where the product is actually
processed. The factory requires processing modules to be highly visible and individually addressable and to support
certain of the same remote commands that are required of the equipment. Other elements of interest include
subsystems for material handling, alignment, and measurement.
9.2 The equipment is responsible for all communications at all times, including messages directed to a specific part
of the equipment. Service requests directed to components of the equipment shall be managed by the equipment to
ensure equipment integrity.
Equipment
Module
Equipment
Equipment
Subsystem
Abstract
Equipment
Element
Equipment
IODevice
Abstract
Equipment
Subsystem
Abstract
Equipment
Module
User
1+
Figure 3
Equipment Object Model
9.3 In Figure 3, two hierarchies are shown. On the left is an inverted interface inheritance hierarchy, and on the
right the concrete subtypes where rules of aggretation are shown. The interface inheritance shows the objects that
define the attributes, state models, and services of the subtype objects as viewed externally. These are presented
upside down from the usual presentation so that they may be directly related to the aggregation hierarchy on the
right. In both cases, the simpler objects are below the more complex objects.
9.4 Those object types starting with the word “Abstract” are abstract objects not intended to be implemented
directly. Their purpose is solely to define the inherited attributes, state models, and services for those objects used
to build an OBEM model of equipment. The remaining objects shown in Figure 3 are concrete objects. All rules of
aggregation are defined for concrete objects only.
SEMI E98-1102 © SEMI 2000, 2002 14
9.5 OBEM Object Requirements — By definition,
subtypes of objects inherit the properties (attributes,
services, and relationships) of their supertypes. In some
cases, properties of the subtype may be further
specialized.
9.5.1 Object Services Requirements — All objects
formally defined by this standard shall be compliant to
the fundamental requirements of SEMI E39 (OSS). All
OBEM-defined objects that are aggregates, containers,
or managers of other objects shall comply with the
additional OSS requirements for object owners.
According to OSS, an owner is any aggregate,
container, or manager of one or more other objects. An
owner is required to respond to queries about the types
of objects that it owns. Owners have additional
responsibilities, as specified in OSS.
9.5.2 Object Non-volatility
9.5.2.1 All objects defined by OBEM shall be
persistent. The individual object persists across
powerdown and powerup conditions, and all current
values of static attributes (attributes that do not change
dynamically indicating the object' s status) shall be
maintained and restored upon powerup. It may be
important to maintain other critical values as well,
depending upon the object and the implementation.
When the equipment is powdered on or reset
5
, all state
models are restored. Following initialization, the object
is considered to be operational. Figure 4 shows this
convention for a generic OBEM object. However,
since the state model can not be accessed by the user
until the object is operational, the default entry state for
a specific state model is considered to be within the
Operational state.
(Persistent OBEM Object)
OPERATIONAL
POWER
DOWN
INITIALIZATION
Figure 4
Persistence of OBEM Objects
5 For a more detailed discussion of powerdown, reset, and soft reset,
see SEMI E58.
9.5.2.2 POWERDOWN and INITIALIZATION are
common to all OBEM objects. Therefore, they are not
specific to any object and are not generally shown.
When operational, the OBEM object is capable of
maintaining state information. From the user view, an
instantiation of an OBEM object shall follow the
behavior or state model as shown in Figure 4. The
equipment representation, which consists of an
aggregation of OBEM objects, shall also reflect the
state model shown here.
9.5.2.3 The equipment is responsible for managing the
exchange of any of its component parts, including parts
exchanged during powerdown. This may be
accomplished through use of intelligent components
that are able to identify themselves or through the user
interface.
9.5.3 Shared Resources — When two (or more) objects
cooperate in using the services provided by a third
object, then the third object should not be modeled as a
component of either of the first two objects. If the two
cooperating objects have a common owner, either
logical or physical, then the shared resource object
should belong to the common owner.
9.5.4 Object Factory Communications — OBEM
objects other than the Equipment object are neither
required nor expected to communicate directly with the
factory. Factory communications are handled by the
Equipment instantiation.
9.5.5 Object Event Reporting
9.5.5.1 Event reporting allows a user to receive
notification of events together with related data of
interest. OBEM compliance requires that the equipment
provide a standard mechanism for reporting events of
interest to the user, together with the current values of
user-selectable data.
9.5.5.2 All transitions in state models are of interest to
the user and reportable unless otherwise stated in the
state model definition.
9.6 OBEM Interface Inheritance Hierarchy
9.6.1 An interface inheritance hierarchy begins with a
simple interface at the highest (most abstract) level, and
lower levels within the hierarchy represent added
functionality (specialization). A subtype of an object
inherits the attributes, behavior, relationships, and
services of the supertype and adds to and/or modifies
(overrides) them.
SEMI E98-1102 © SEMI 2000, 2002 15
AbstractEquipment
Element
Equipment
AbstractEquipmentModule
AbstractEquipment-
Subsystem
Figure 5
Object Interface Hierarchy Concept
9.6.1.1 The physical view shown in Figure 2 is
concerned with the relationships between different
objects. In that view, the equipment is at the highest
level and owns (is responsible for) the lower level
objects of which it is made up. A process chamber is
considered to be at a higher level than subsystems such
as substrate handlers.
9.6.1.2 From the view of the object interface hierarchy,
this order is reversed, with AbstractEquipmentElement
appearing at the top level as shown in Figure 5. From
the view of an object interface — the interface to an
object — the higher the level, the more simple the
interface. This is because of inheritance, where the
“child” object inherits all of the attributes, behavior,
and services of the “parent” object and at the same time
adds some degree of specialization that will be reflected
in either additional attributes, behavior, or services, or
in restrictions on the more general object.
9.6.1.3 All objects represent the view as seen by the
factory, not the internal view of equipment control.
From this view, the information and services required
for an equipment part such as a pod door opener is
relatively simple. The view of a module such as a
process chamber is more complex but contains all the
elements of the view provided for the simpler part
(functional description, immutable id, etc.). The view
of the equipment is the most complex and includes all
of the attributes and services of the equipment element,
equipment subsystem, equipment module, and the
equipment itself.
9.6.1.4 The object model of equipment presented to the
factory is based on SEMI E39 (OSS). OSS services
allow the factory to “discover” the actual physical
makeup and aggregation hierarchy of the physical view
of equipment illustrated in Figures 2 and 3.
9.6.1.5 Each object is defined in terms of its
requirements, attributes, behavior (state models), and
the services that it is required to support. The
equipment owns all of the objects that it is made of and
is responsible for providing the required behavior.
9.6.1.6 All objects in OBEM inherit the attributes and
services defined for the Top Object as specified in the
Object Service Standard (OSS). This allows the factory
to use object services to request the equipment to
describe its physical view by reporting which objects
that it owns.
9.6.1.7 Note that equipment support for an OBEM
interface to the factory does not imply or require direct
access from the factory to any equipment element.
10 OBEM Object Definitions
10.1 OBEM objects are defined in this section.
10.2 AbstractEquipmentElement Object — The
supertype object of the interface hierarchy is
AbstractEquipmentElement, which is an abstraction of
any equipment component that can perform work.
AbstractEquipmentElement is an abstract type that is
not implemented directly. There are two subtypes of
AbstractEquipmentElement: AbstractEquipmentSub-
system, and EquipmentIODevice. AbstractEquipment-
Element is an abstract type, so that implementations are
of one of the subtypes.
10.2.1 AbstractEquipmentElement Requirements
10.2.1.1 Object Exception Management
10.2.1.1.1 SEMI E41 defines a model for Exception
Conditions. An Exception Condition may be either an
Alarm Condition or an Error Condition. Error
Conditions may, in some cases, have a set of associated
Recovery Actions that can be performed by the
AbstractEquipmentElement to attempt to recover from
the abnormal situation.
10.2.1.1.2 An OBEM object shall comply with the
fundamental requirements of SEMI E41, Section 10.4.
Exception Condition objects shall be provided in
conformance with SEMI E41 and shall be accessible
through services defined in SEMI E39. The
AbstractEquipmentElement owns all exceptions that it
generates. Therefore, it shall report all of its Exception
Condition objects through OSS services.
10.2.2 AbstractEquipmentElement Subtypes — The
AbstractEquipmentElement has two subtypes, the
EquipmentIODevice and the AbstractEquipment-
Subsystem.