semi合集-English.pdf - 第1862页

SEMI E53-0704 © SEMI 1996, 2004 2 4.1.3 collection event — an e vent that may be used to initiate the collection and reporting of data. A collection event may trigger an ev ent report. A collection ev ent may also start …

100%1 / 7923
SEMI E53-0704 © SEMI 1996, 2004 1
SEMI E53-0704
EVENT REPORTING
This standard was technically approved by the Global Information & Control Committee and is the direct
responsibility of the Japanese Information & Control Committee. Current edition approved by the Japanese
Regional Standards Committee on April 30, 2004. Initially available at www.semi.org June 2004; to be
published July 2004. Originally published December 1996.
1 Purpose
1.1 Access to process data in equipment is crucial for
effective process monitoring and control in a
semiconductor manufacturing facility. This standard
addresses the communication needs of semiconductor
equipment and other factory objects, such as cell
controllers or recipe servers, with respect to the timely
collection and reporting of such data.
1.2 The purpose of this standard is to provide a general
purpose set of event reporting services that may be
offered by equipment suppliers. This document may be
referenced, in whole or in part, by other standards
addressing higher level application domains.
1.3 The communications services defined here will
enable standards based inter-operability of independent
systems. They shall allow application software to be
developed which can assume the existence of these
services and allow software products to be developed
which offer them.
2 Scope
2.1 This standard is applicable to any stand-alone
equipment, cluster module, cluster tool, or cell of
automation in a factory. As such it addresses event
reporting at all levels in the factory and equipment
control hierarchy.
2.2 This standard requires significant communication
and computational resources and is therefore not
applicable at or below the level of I/O distribution (e.g.,
sensor bus) within the equipment.
2.3 This standard covers the reporting of data
periodically and/or in response to events. Reports may
also be requested on demand.
2.4 This standard presents a solution from the concepts
and behavior down to the messaging services. It does
not define the messaging protocol.
2.5 A messaging service includes the identification that
a message shall be exchanged and definition of the data
which is contained in that message. It does not include
information on the structure of the message, how the
data is represented within the message, or how the
message is exchanged. This additional information is
contained with the message protocol. The defined
services may be applied to multiple protocols.
Information on the mapping of these services to special
protocols (e.g., SECS II) are added as adjunct
standards.
2.6 The services assume a communications
environment in which a reliable connection has been
established between the user and the provider of the
services. Establishing, maintaining, and releasing a
connection is beyond the scope of this standard.
NOTICE: This standard does not purport to address
safety issues, if any, associated with its use. It is the
responsibility of the users of this standard to establish
appropriate safety and health practices and determine
the applicability of regulatory or other limitations prior
to use.
3 Referenced Documents
3.1 SEMI Standards
SEMI E5 — SEMI Equipment Communications
Standard 2 Message Content (SECS-II)
SEMI E30 — Generic Model for Communications and
Control of SEMI Equipment (GEM)
SEMI E38 — Cluster Tool Module Communications
(CTMC)
SEMI E39 — Object Services Standard: Concepts,
Behavior, and Services
SEMI E40 — Standard for Processing Management
NOTICE: Unless otherwise indicated, all documents
cited shall be the latest published versions.
4 Terminology
4.1 The following definitions are arranged in
alphabetical order. Some terms are defined using terms
defined elsewhere within this section. Other terms may
be defined within SEMI’s Compilation of Terms.
4.1.1 attribute — a data item associated with an object.
An attribute may be referenced by zero or more data
reports.
4.1.2 behavior — the manner in which something
functions; how an object acts and reacts, in terms of its
state changes and message passing.
SEMI E53-0704 © SEMI 1996, 2004 2
4.1.3 collection event — an event that may be used to
initiate the collection and reporting of data. A collection
event may trigger an event report. A collection event
may also start or stop one or more trace reports.
4.1.4 data report — a data report is a list of attribute
names for a single object. Data reports may be pre-
defined by a factory object or defined dynamically by
the service user.
4.1.5 default object — the object assumed when no
object specifier is supplied.
4.1.6 event — represents the occurrence of a change in
the condition of a system (e.g., lot complete,
temperature over range).
4.1.7 event report — a class of objects that has
information related to an event and can be linked to
user defined data reports and can send messages
containing this information to a service user.
4.1.8 factory object — any identifiable object within
the factory information and control architecture.
Examples include equipment, a cluster process module,
a cell controller, a recipe namespace server.
4.1.9 object — defined in the Object Services (SEMI
E39).
4.1.10 object specifier — defined in the Object
Services (SEMI E39).
4.1.11 services — a set of closely related messages.
4.1.12 service provider — a service provider is an
application responsible for providing services to service
users.
NOTE 1: There may be one or more service users
concurrently accessing a single service provider. It is the
responsibility of the service provider to provide its services
transparently to each service user.
4.1.13 service user — a service user is any application
that uses the services.
4.1.14 trace report — a class of objects which provides
to a service user a means for collecting periodic
readings of selected attributes of a system.
4.2 Data Types
4.2.1 form — type of data: float, positive integer,
unsigned integer, integer, enumerated, boolean, text,
formatted text, structure, list, ordered list.
4.2.2 float — a number represented by a mantissa and
an exponent. It is used to represent numeric data which
is continuous in value.
4.2.3 positive integer — May take the value of any
positive whole number. Messaging protocol may
impose a limit on the range of possible values.
4.2.4 unsigned integer — May take the value of any
positive integer or zero. Messaging protocol may
impose a limit on the range of possible values.
4.2.5 integer — May take the value of any negative or
unsigned number. Messaging protocol may impose a
limit on the range of possible values.
4.2.6 enumerated — May take on one of a limited set
of possible values. These values may be given logical
names, but they may be represented by any single-item
data type.
4.2.7 boolean — May take on one of two possible
values; TRUE or FALSE.
4.2.8 Text — A text string. Messaging protocol may
impose restrictions, such as length or ASCII
representation.
4.2.9 formatted text — a text string with an imposed
format. This could be by position, by use of special
characters, or both.
4.2.10 structure — a complex structure consisting of a
specific set of items, of possibly mixed data types, in a
specific arrangement.
4.2.11 list — set of one or more items that are all of the
same form (one of the above forms).
4.2.12 ordered list — s list for which the order in
which the items appear is significant.
5 Conventions
5.1 Harel State Model — This document uses the Harel
State Chart notation to describe the dynamic behavior
of the objects defined. An overview of this notation is
presented in an appendix of SEMI E30. The formal
definition of this notation is presented in Science of
Computer Programming 8, “Statecharts: A Visual
Formalism for Complex Systems,” by D. Harel, 1987.
5.1.1 Transition tables are provided in conjunction with
the state diagrams to explicitly describe the nature of
each state transition. A transition contains columns for
transition #, current state, trigger, new state, action(s).
The “trigger” (column 3) for the transition occurs while
in the “current” state. The “actions” (column 5) include
a combination of; 1) actions taken upon exit of the
current state, 2) actions taken upon entry of the new
state, and 3) actions taken which are most closely
associated with the transition. No differentiation is
made.
5.2 OMT Object Information Model — The object
models are presented using the Object Modeling
Technique developed by Rumbaugh, James, et al, in
“Object-Oriented Modeling and Design,” Prentice Hall,
Englewood Cliffs, NJ, ©1991. Overviews of this
SEMI E53-0704 © SEMI 1996, 2004 3
notation are provided in an appendix of the Object
Services SEMI E39.
5.3 Object Attribute Representation — The object
information models for standardized objects will be
supported by an attribute definition table with the
following column headings:
Attribute Definition Rqmt Access Form
The formal
text name of
the attribute
Description
of the
information
contained
Y or N RO or RW (see below)
5.3.1 The access column uses RO (read only) or RW
(read and write) to indicate the access that users of
object services have to the attribute.
5.3.2 A ‘Y’ or ‘N’ in the requirement (rqmt) column
indicates if this attribute must be supported in order to
meet fundamental compliance for the service.
5.3.3 The form column is used to indicates the format
of the attribute. See Section 4.2 for definitions.
5.4 Service Message Representation
5.4.1 Service Resource Definition — The service
resource definition table defines the specific set of
messages for a given service group, as shown in the
following table:
Service Type Description
Message name N or R The intent of the service
5.4.1.1 Type can be either notification (N) or request
(R). Notification messages are initiated by the service
provider. No response is expected. Request messages
are initiated by the service user. Request messages ask
for data or for an operation to be performed. Request
messages expect a specific response (no presumption
on the message content).
5.4.2 Service Parameter Dictionary — Each parameter
should relate to either attributes from the object model
or events of the dynamic model (Harel State Chart). All
parameters to the services are listed in a single table or
dictionary. The column headings for this parameter
dictionary are as follows:
Parameter Description Form
Parameter X Data type A parameter
5.4.2.1 A row is provided in the table for each
parameter of the service. The first column contains the
name of the parameter. This is followed by columns
describing the form and the contents of the parameter.
5.4.2.2 The description column describes the meaning
of the parameter and interrelationships with other
parameters.
5.4.2.3 The form column is used to indicate the type of
data contained in the parameter (see Section 4.2 for
definitions) and the possible values it may take on.
5.4.2.4 To prevent definition of numerous parameters
named “XxxList,” this document adopts the convention
of referring to the list as “(list of) Xxx.” In this case,
the definition of the parameter “Xxx” will be given, not
of the list. Where a list is used in both the request and
the response, the list order in the request is retained in
the response. A list must contain at least one element
unless zero elements are specifically allowed.
5.4.3 Service Message Definition — There is a table for
each service showing the parameter detail. The column
headings for the service detail are as follows:
Parameter Req/ Ind Rsp/ Cnf Comment
Parameter X (see below) (see below) A description
of the service
5.4.3.1 The columns labeled req/ind and rsp/cnf link
the parameters to the direction of the message. The
message sent by the initiator is called the “request”
(req). The receiver terms the message the “indication”
(ind). The receiver may then send a “response” (rsp),
which the original sender terms the “confirmation”
(cnf).
5.4.3.2 The request (req/ind) and response (rsp/cnf)
entries can take on the following values:
“M” Mandatory parameter — Must be given a valid
value.
“C” Conditional parameter — May be defined in some
circumstances and undefined in others. Whether a
value is given may be completely optional or may
depend on the value of another parameter.
“U”
User-defined parameter
“-” The parameter is not used.
“=” The entries M and C in the response can be modified
with (=) to indicate that the value in the response must
match the request.
6 Overview
6.1 Event reporting provides a dynamic and flexible
means by which the service user can receive
notification of events and data relating to objects
defined here and in other SEMI standards.