semi合集-English.pdf - 第1664页
SEMI E39-0703 © SEMI 1995, 2003 6 5.3.1.3 Request messages are initiated by a service consumer or s ubscriber. Request messages ask for data or an activity from the provider. Request messages expect a specific response m…
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
SEMI E39-0703 © SEMI 1995, 2003 7
object-oriented technologies and those using traditional
technologies. Object information models provide a
powerful method for describing relationships that can
be intuitively understood.
8.1.2 For those unfamiliar with object-oriented
terminology, a brief discussion of terms is provided in
the Appendix.
8.2 Object Attributes — An object attribute is a data
value that is held by all instances of a given object type.
For communication purposes, public attributes are
assigned a logical name that is unique for that object.
An object' s attributes may be individually referenced
either by an enumerated numeric value or by a reserved
attribute name that conforms to the use of text defined
in Section 8.1.1.
8.2.1 An attribute that can be requested or referenced
through formal public services is a public attribute.
Other attributes may exist in specific implementations
but are invisible through public services and are called
private attributes.
8.2.2 Specific attributes may be designated as
fundamental for a specific object. These shall be
supported by all implementations that use or reference
the specified object. Attributes that are not fundamental
are optional.
8.2.3 Use of Text — Values defined as text, when
given in ASCII, are subject to certain restrictions. This
includes object attribute values, attribute names, and
service parameters.
8.2.3.1 Text in ASCII is restricted to the characters
between 20
16
and 7E
16
, excluding the question mark
“? ”, the asterisk “*”, and the tilde “~ ”.
8.2.3.2 The question mark and asterisk are reserved for
use as “wild characters” in filters and searches, while
the tilde is reserved to allow systems that cannot use
spaces to convert spaces to tildes for internal use.
8.2.3.3 Text used in specific contexts may have
additional restrictions.
8.2.3.4 Unless otherwise stated, case is not significant
for purposes of comparison. However, case is used to
improve readability and should be preserved whenever
possible.
8.2.4 Object Type — An object always knows its type.
For this reason, the attribute for object type, ObjType
,
is required for all public objects. ObjType
is a text
string containing the formal classification of an object.
The text string shall conform to the convention defined
in Section 8.1.1, with the additional restriction that the
“greater than” symbol “>” and the colon “:” are also
excluded. The text string shall not start or end with a
space.
8.2.4.1 Object types (the values for ObjType
) for
standardized objects are reserved. Types reserved are
specific to individual standards.
8.2.5 Object Identifier — Every instance of an object
shall have one or more attributes that together uniquely
distinguish that instance from all other instances of
objects of the same object type. An object may have
more than one identifier. The identifier(s) are defined as
part of the object definition.
8.2.5.1 ObjID
is a text-based fundamental attribute of
all public objects and provides an attribute of a known
form to serve as an identifier for an object of any type.
The text string shall conform with the convention
defined in Section 8.1.1 and with the additional
restriction that the “greater than” symbol “>” and the
colon “:” are also excluded. The text string shall not
start or end with a space.
8.2.5.2 From the point of view of objects such as
managers, aggregates, and containers that have
responsibilities for other objects (see Sections 9.1 and
9.2) the combination of ObjType
and ObjID for these
other objects shall be unique. For example, if several
process chambers have a single vacuum pump, each
process chamber may have direct access to at most one
ObjType
:ObjID> combination of “Pump:Vacuum”.
However, the combination is not required to be unique
across the different chambers. The host differentiates
between the several vacuum pumps by their belonging
to different aggregations.
8.2.5.3 The object definition for each object shall
specify the particular identifier used for general access.
For objects that normally use an identifier with a
numeric value as an identifier (such as “handle,”
described below), the value of ObjID
is a numeric text
string set to the value of that attribute.
8.2.5.4 An object may also have other identifiers in
addition to ObjID.
8.2.6 Object Handle — An object' s handle is an
attribute with a numeric value that is assigned by the
application that created the object. The handle may be
used for the object' s identifier. It is generally intended
for local use and may or may not be defined as a public
attribute in the object' s formal definition.
8.2.6.1 Where used, the handle may be guaranteed to
be unique only within a specific context and within a
single association between service-provider and
service-user for a specific service resource. The handle
may or may not be persistent beyond a certain context
within that association or beyond it. Persistence of the
handle is specified as part of the definition of the object
and is beyond the scope of OSS.