semi合集-English.pdf - 第1865页

SEMI E53-0704 © SEMI 1996, 2004 5 providers in each connected module would be the default obje ct. For example, the processing management service of PM:ETCH woul d be a default object for that m odule connection. But, th…

100%1 / 7923
SEMI E53-0704 © SEMI 1996, 2004 4
6.2 Figure 1 illustrates a simple event reporting
situation.
Provider
User Defined Confi
g
uration
- Trace Reports
- Data Re
p
orts
- Links to Event Reports
Provider Defined Confi
g
uration
- Trace Reports
- Data Re
p
orts
- Links to Event Reports
Collection Events & Data
User
Request
Notification
Figure 1
Simple Event Reporting
6.3 Event and variable identifiers may be defined by
another standard with which equipment or an object
complies. In either case, the definitions must be
included in the documentation from the supplier.
6.4 The service user may define and access data reports
using the event reporting request services. Data reports
are sampled and sent by the service provider using the
event reporting notification services.
6.5 Data reports may be pre-defined by the supplier.
Such reports cannot be deleted and their report
identifiers may not be used for dynamically created
reports.
6.6 Multiple Service Users — In a more complex
situation, several service users may require
simultaneous access to the event reporting services
(ERS). In this case, the service provider manages data
report definitions independently for each service user as
shown in Figure 2. A copy of each pre-defined report is
made for each service user. Support for more than one
simultaneous service user is optional.
Provider
Collection Events & Data
Provider Defined Confi
g
uration
User Defined
Confi
g
uration
Provider Defined
Confi
g
uration Co
py
User Defined
Confi
g
uration
Provider Defined
Confi
g
uration Co
py
User
User
Figure 2
Multiple Service Users
6.7 Using Object Services — An event reporting
service user can create reports dynamically by
accessing attribute information using the object services
(see SEMI E39) when they are provided (see Figure 3).
User
Object
Services
Provider
Event
Re
p
ortin
g
Provider
Collection Events and Data
Figure 3
Using Object Services
7 Concepts
7.1 Objects and Identifiers — Much of the discussion
and specification for event reporting services relies on
an understanding of object technology and modeling
techniques. The use of object technology for ERS
implementations is not required. Further, it is not
required that ERS implementations be compliant to the
Object Services Standard (OSS). This standard does
specifiy mechanisms by which ERS can take advantage
of OSS when those services are provided.
7.1.1 Events are associated with an object and data is
stored in object attributes. To uniquely identify an event
or an attribute the object to which it relates must first be
identified.
7.1.2 An object may be a physical entity such as stand-
alone process equipment, a cluster tool or a cluster
module. An object may be an abstraction such as a
recipe, a process job or a transfer job. An object may be
defined by the equipment supplier, or by a standard
with which the equipment complies. An example of a
cluster tool, containing process modules, is used in this
section as the service provider. This example is for
illustration purposes only. The same concepts apply for
all factory objects as defined above.
7.1.3 Objects may be part of an object hierarchy or
contained in other objects. The default object is the
object which provides the service connection. In the
case for batch processing equipment which is compliant
to GEM, SEMI E30, the connection to the host is
provided by the equipment and the equipment is the
default object. Also, a cluster controller would be the
default object of equipment containing process
modules. However, from the point of view of the
cluster controller, each connection to the service
SEMI E53-0704 © SEMI 1996, 2004 5
providers in each connected module would be the
default object. For example, the processing
management service of PM:ETCH would be a default
object for that module connection. But, the cluster
controller would have differernt default objects on each
of its other service connections.
7.1.4 An object specifier, (see SEMI E39), identifies an
object within the scope of the service provider. An
object specifier consists of one or more object type and
object instance identifier pairs. For example,
“PM:ETCH>” might be the object specifier of a process
module (type=PM, identifier=ETCH) within a cluster
tool. If the object specifier is omitted, then the default
object is assumed.
7.1.5 Objects are considered local to the service
provider even if they exist on a remote module. That
means the service provider is responsible for detecting
events and accessing data from those objects in a timely
manner, by whatever means, to provide the specified
services.
7.1.6 Equipment which implements OSS-compliant
event reporting services allows the service user to
reference equipment components by an object specifier;
for example, “PM:ETCH>MFC:CCL4.”
7.2 Event Report Object Model — Figure 4 shows the
objects, attributes (variables), and relationships
involved in event reporting. The notation used is
defined in Section 5. The diagram illustrates the
relationships between the service’s messages and
attributes (variables). The objects and their attributes
are defined Section 8. Only the trace, data report,
collection event, and data source objects’ attributes and
behaviors are standardized in that section. Note that this
model presents a view of event reporting services from
the perspective a single user. It is optional for the
service provider to support simultaneous access from
multiple service users. But for that option the provider
shall present this view to each user independently.
Figure 4
Event Report Object Model
SEMI E53-0704 © SEMI 1996, 2004 6
Figure 5
Trace Object Information Model
7.2.1 Service Provider Object — The service provider
is responsible for compiling report samples according
to each service user setup. It detects collection events,
provides trace timing and accesses the value of data
source object attributes (variables) in order to compile
the data reports. ERS does not specify the attributes or
behavior of this object. It is included in the event report
object model to provide context for other objects within
ERS.
7.2.2 Service User Object — The service user is
responsible for configuring its own event reporting
setup and receives reports from the service provider
according to that setup. ERS does not specify the
attributes or behavior of this object. It is included in the
event report object model to provide context for other
objects within ERS. However, the service user object
shall be able to receive the event report send and trace
report send messages from the service provider.
7.2.3 Collection Event Object — This object type or
class is responsible to provide all the collection event
identifiers for which event reports can be generated.
Other factory services and objects may provide event
notification messages which are important in the
context of a service or functionality that they provide.
But, in general, these notifications do not provide
mechanisms to report information beyond their domain
boundaries. For example, Processing Management,
SEMI E40, includes an event notification for process
complete (PRJobAlert (Milestone)). In order to collect
data associated with this event, it must be “known” to
the collection event object type. When it is “known” by
the collection event object, then event reports can be
generated using data or attributes from the data sources
which are “known” by the event reporting service
provider. A data source could provide information on
process chamber pressure and temperature, which are
attributes or variables important to the process but
which are not known to the processing management
service.
7.2.4 Event and Data Source Objects — The use of the
event source and data source objects provides extensive
capability to access the attributes of objects in a
distributed environment. Where the event services
provider has a domain which extends over multiple
resources, such as a cell controller for a furnace bay or
a cluster tool controller, these objects provide an
unambiguous mechanism for addressing the data that
the service user wishes to access.
7.2.4.1 The event and data source objects are to the
event reporting services what directory object is in a
file system of a computer’s operating system. They
should be thought of as containers of information which
provide pointers (or names) of objects that are the
actual sources of events or data.
7.2.4.2 The event source object is not directly
accessible to the service user. Knowledge of events and
event sources can be accumulated by interrogation of
the collection event object using OSS.
7.2.4.3 Collection event identifiers shall be determined
by either of two possible methods. One, the equipment
supplier may define and supply with the equipment a
list of collection event IDs (identifiers). Two, the
equipment’s collection event object can be interrogated
with object services requests for collection event
sources and identifiers. For example, using the second
method, one could use object services to ask the
collection event object for a list of collection event
sources, which might include objects such as
“PM:Etch>MFC:CCL4” or “TM>Aligner.” Then using
OSS, the collection event object can be queried for
events associated with these sources. For the MFC a list
of events might include “preslow,” “overlimit,”
“valvemax,” etc.
7.2.5 Data Report Object — A data report defines the
variables (or attributes) of a specific object (data
source) which are to be sampled. Data reports are either
pre-defined or defined dynamically by the service user.
A data report sample is a set of data containing the
values of the variables defined for the data report. To
sample a data report means that the current values of
the variables at their data source object should be
recorded. Data reports may be sampled and sent either
with an event report and/or with a trace report. The
service user may request:
• To sample an individual data report.
• Create a data report.