semi合集-English.pdf - 第2748页
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 independe ntly opera ble, are very intere sting to the factory, since …
SEMI E98-1102 © SEMI 2000, 2002 12
Table 1 Functional Area Definition
Functional Area Where Defined Comments
Access Management SEMI E98 (OBEM) Defines different kinds of user control.
Date/Time Management SEMI E98 (OBEM) Addresses timestamp, date/time synchronization.
Event Management SEMI E53 (ERS) SEMI E53 may be required for SECS-II implementations.
Exception Management SEMI E41 (EMS) Required for reporting alarms and exceptions.
Material I/O Management SEMI E87 (CMS) Required for Carrier Management.
Material Management SEMI E90 (STS) Required for Substrate Tracking.
Object Management SEMI E39 (OSS) Required
Operations Management SEMI E98 (OBEM) Overall coordination.
Performance Management SEMI E58 (ARAMS) Optional for EquipmentModule and Equipment. Not used
for lower level components.
Job Management SEMI E40 (PM),
SEMI E94 (CJM)
Process Managment and Control Job Management
Recipe Execution SEMI E42 (RMS) Required for processing by EquipmentModule.
Recipe Management SEMI E42 (RMS) Required for long-term storage by Equipment.
8.5 Internal Composition View of the Equipment — The physical makeup of equipment is of interest to the factory,
particularly for equipment that is complex, multi-module, and/or multi-process. Productivity and maintenance
tracking, for example, requires that the factory be able to specify individual subsystems and/or modules for
maintenance activities, where it is possible to do so without removing the entire equipment from manufacturing
scheduling. For example, one or more baths in a wet bench may be down for maintenance even though the wet
bench itself continues to process.
1+
1+
held at
interacts with
EquipmentClock
Process
Module
Material
Handling
Subsystem
I/O Device
User
Carrier
LoadPort
1+
Figure 2
An Example of Equipment Internal Composition
9 OBEM Object Model
9.1 OBEM defines generic component objects of Equipment, and the Equipment object itself. Equipment is made
up of elements (units or parts) of different levels of intelligence and complexity, such as modules, subsystems, and
I/O devices. Each of these elements may itself be made up of several smaller elements, some of which may also be
intelligent, and this allows the complexity of the equipment to be distributed to smaller functional units. Many of
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.