semi合集-English.pdf - 第1663页
SEMI E39-0703 © SEMI 1995, 2003 5 facility and an indication to the receive r from the communications facility. 4.2.3.4 request service — initiated by the service consumer. Requests ask for data or for an activity (opera…
SEMI E39-0703 © SEMI 1995, 2003 4
4.2.2.5 object instance — an instance of an object type.
An object type is like a template, while an object
instance is the actual object. Example: an actual and
specific optical stepper installed in a particular fab is an
instance of the type “Optical Stepper.”
4.2.2.6 object attribute (attribute) — information
concerning an object. Examples for object type
“equipment”: manufacturer, model, serial number.
4.2.2.6.1 Attributes are classified in various ways,
according to their visibility (public/private), optionality,
and access:
• fundamental attribute — an attribute that is
required for fundamental compliance with a
standard service.
• optional attribute — an attribute that is required
only in support of one or more optional standard
services.
• private attribute — an attribute that is used strictly
for internal purposes and is unknown (invisible)
through public services.
• public attribute — an attribute that is known
(visible) and whose current value is provided as a
service to other entities upon request.
• read-only attribute (RO) — may not be changed
through public services.
• read/write attribute (RW) — may be changed
through public services.
4.2.2.7 attribute name — the formal name of the
attribute that is used to identify it. The names (and data
types) of public attributes are included with the object’s
definition and are unique for that object.
4.2.2.8 object identifier — a set of one or more items
of information, concerning a particular instance
(instantiation) of an object of a given type, that together
uniquely distinguish that instance from all other
instances of that object within a defined scope. NOTE:
An object may have more than one identifier. An
identifier may be simple (consist of only one attribute)
or complex (consist of more than one attribute).
Example: The combination of equipment' s
manufacturer, model, and serial number serve as an
identifier that uniquely identifies a specific installation.
4.2.2.9 object handle — a numeric or binary identifier
assigned by an application for internal use. NOTE: A
handle may also be available as a public attribute but
cannot generally be guaranteed to be either persistent or
unique outside of the current relationship between
service user and service provider. The persistence of the
handle is specified by the standard that defines the
object.
4.2.2.10 operation — a function performed by, or
inherent to, an object. Example: for equipment, “run,”
“stop,” “abort.”
4.2.2.11 aggregation object — an object that is
composed (made up) of other objects. An aggregation
may lose some degree of integrity if one of its
components is missing.
4.2.2.12 component object — an object that is part of
an aggregation.
4.2.2.13 container object — an object that is intended
to hold other types of objects. The contents may or
may not be ordered.
4.2.2.14 contents — an object that is in a container.
Examples: a wafer in a cassette, a book in a library.
4.2.2.15 owner object — an object that is an
aggregation, container, or supervisor of another object.
The owner object is said to own the other object.
4.2.2.16 owned object — an object that is a component
of, contained in, or supervised by, another object. The
owned object is said to be owned by the other object.
4.2.2.16.1 An object may have multiple owners. For
example, it may be a shared resource.
4.2.3 Services
4.2.3.1 scope — the specification of one or more
objects that starts with a specific owner object and
proceeds downward through a hierarchical sequence of
“owns” relationships.
4.2.3.2 service (or message service) — represents a
function offered to a user by a provider. A service
consists of a sequence of service primitives, each
described by a list of parameters. A service excludes
definition of message structure and protocol.
4.2.3.2.1 A service may or may not be processed by the
provider of the service. The invocation of some service
may have to interact with other objects to fulfil its
requirement completely; an exception will be raised if
the service can not fulfill all its pre or post conditions.
The object that provides the service may reject the
service request or restrict the completion of the service
to prevent an illegal action due to the equipment
condition.
4.2.3.3 notification service — initiated by the service
provider and sent to the service consumer/subscriber.
No response is expected.
3
4.2.3.3.1 Notifications consist of two service primitives
— a message from the sender to the communications
3 This does not preclude the implementation of a response message
in the message protocol.
SEMI E39-0703 © SEMI 1995, 2003 5
facility and an indication to the receiver from the
communications facility.
4.2.3.4 request service — initiated by the service
consumer. Requests ask for data or for an activity
(operation) from the provider. Requests expect a
specific response message.
4.2.3.4.1 A request consists of a message that requires
a response from the receiver. The primitives for a
request are the same as those of the notification, while
the response defines additional primitives called the
response and the confirmation.
4.2.3.5 service resource — a logical group of one or
more services within a specific area of functionality.
4.2.4 Data Type
4.2.4.1 form — type of data: positive integer, unsigned
integer, integer, enumerated, boolean, text, formatted
text, structure, list, ordered list.
4.2.4.2 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.3 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.4.4 integer — may take on the value of any
negative or unsigned integer. Messaging protocol may
impose a limit on the range of possible values.
4.2.4.5 floating point — may take on any single (real)
numeric value, positive or negative. Messaging protocol
may impose a limit on the range of possible values.
4.2.4.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.4.7 boolean — may take on one of two possible
values, equating to TRUE or FALSE.
4.2.4.8 text — A text string. Messaging protocol may
impose restrictions, such as length or ASCII
representation.
4.2.4.9 formatted text — a text string with an imposed
format. This could be by position, by use of special
characters, or both.
4.2.4.10 structure — a complex structure consisting of
a specific set of items, of possibly mixed data types, in
a specified arrangement.
4.2.4.11 list — a set of one or more items that are all of
the same form (one of the above forms).
4.2.4.12 ordered list — a list for which the order in
which items appear is significant.
5 Conventions
• Defined terms are presented in boldface when
introduced for the first time.
• Formally reserved text strings, such as attribute
names, are underlined.
5.1 OMT Object Information Model — The object
models are presented using the Object Modeling
Technique (OMT) developed by Rumbaugh, James, et
al, in Object-Oriented Modeling and Design, Prentice
Hall, Englewood Cliffs, NJ, c1991.
4
5.1.1 Overviews of this notation are provided in the
Appendix. A brief discussion of terminology is also
provided in the Appendix.
5.2 Object Attribute Representation — The object
information models for standardized objects will be
supported by an attribute definition table with the
following column headings:
Attribute Name Definition Access Rqmt Form
The formal text
name of the
attribute
Description of
the information
contained
RO or
RW
Y or N (See
Section
4.2.4.)
5.2.1 The Access column uses RO (Read Only) or RW
(Read and Write) to indicate the access that users of the
service have to the attribute.
5.2.2 A “Y” or “N” in the Requirement (Reqt) column
indicates if this attribute must be supported in order to
meet fundamental compliance for the service.
5.2.3 The Form column is used to indicate the format
of the attribute. (See Section 4.2.4 for definitions.)
5.3 Service Message Representation
5.3.1 Service Resource Definition — A service
resource definition table defines the specific set of
messages for a given service group, as shown in the
following table:
Message Service Name Type Description
Message name N or R The intent of the service.
5.3.1.1 Type can be either N = Notification or R =
Request.
5.3.1.2 Notification type messages are initiated by the
service provider, and the provider does not expect to get
a response from the consumer/subscriber.
4 For a full description of the Object Modeling Technique, see
Object-Oriented Modeling and Design, Rumbaugh, Blaha,
Premerlani, Eddy and Lorenson, Prentice Hall, 1991.
SEMI E39-0703 © SEMI 1995, 2003 6
5.3.1.3 Request messages are initiated by a service
consumer or subscriber. Request messages ask for data
or an activity from the provider. Request messages
expect a specific response message (no presumption on
the message content).
5.3.2 Service Parameter Dictionary — A service
parameter dictionary table defines the parameters for
one or more services, as shown in the following table:
Parameter Form Description
Parameter X Data type A parameter called X is B in A.
5.3.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 contents of the corresponding
primitive.
5.3.2.2 The Form column is used to indicate the type of
data contained in a parameter. (See Section 4.2.4 for
definitions.)
5.3.2.3 The Description column in the Service
Parameter Dictionary table describes the meaning of the
parameter, the values it can assume, and any
interrelationships with other parameters.
5.3.2.4 To prevent the 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 variable Xxx will be
given, not of the list. The term “list” indicates a
collection (or set) of zero or more items of the same
data type. 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.3.3 Service Message Definition — A service message
definition table defines the parameters used in a service,
as shown in the following table:
Parameter Req/Ind Rsp/Conf Description
Parameter X (see below) (see below) A description of the
service.
5.3.3.1 The columns labeled Req/Ind and Rsp/Conf
link the parameters to the direction of the message. The
message sent by the initiator is called the “Request.”
The receiver terms this message the “Indication” or the
request. The receiver may then send a “Response,”
which the original sender terms the “Confirmation.”
5.3.3.2 The following codes appear in the Req/Ind and
Rsp/Conf columns and are used in the definition of the
parameters (e.g., how each parameter is used in each
direction):
• “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 values of other
parameters.
• “U” — User-Defined Parameter
• “-” — The parameter is not used.
• “=” — (for response only) Indicates that the value
of this parameter in the response must match that in
the primary (if defined).
6 Background
6.1 During the development of proposals for several
other service standards, it was discovered that they
shared a common need for terminology and services
related to objects. Originally each proposal included a
service-specific message for getting the values of an
object' s attributes, and some also provided a service-
specific message for setting these values.
6.1.1 The decision was made to eliminate this
redundancy through provision of a standard to provide
those definitions and services used by the other separate
service standards.
7 Applicable Documents
SEMI Book of Standards, Equipment Automation/
Software Volumes 1 and 2
5
ISO/TR 8509:1987,
6
Information Processing Systems,
Open Systems Interconnection — Service Conventions
William Stallings, Networking Standards, A Guide to
OSI, ISDN, LAN, and MAN Standards, Addison-Wesley
Publishing Company
8 Basic Concepts and Behavior
8.1 This section defines the concepts and behavior that
are common to public objects.
8.1.1 Object-oriented analysis is a widely accepted
tool, both for applications that are implemented using
5 This set of documents may be obtained from SEMI, 3081 Zanker
Road, San Jose, CA 95134.
6 International Organization for Standardization, ISO Central
Secretariat, 1, rue de Varembé, Case postale 56, CH-1211 Geneva 20,
Switzerland. Telephone: 41.22.749.01.11; Fax: 41.22.733.34.30
Website: www.iso.ch