semi合集-English.pdf - 第1662页

SEMI E39-0703 © SEMI 1995, 2003 4 4.2.2.5 object i n stance — an instance of an object type. An object type is like a template, wh ile an object instance is the actual object . Example: an actual and specific optical ste…

100%1 / 7923
SEMI E39-0703 © SEMI 1995, 2003 3
SEMI E39-0703
OBJECT SERVICES STANDARD: CONCEPTS, BEHAVIOR, AND
SERVICES
This standard was technically approved by the Global Information & Control Committee and is the direct
responsibility of the North American Information & Control Committee. Current edition approved by the
North American Information and Control Committee on March 12, 2003. Initially available at www.semi.org
May 2003; to be published July 2003. Originally published in 1995; previously published November 2002.
1 Purpose
1.1 The purpose of the Object Services Standard (OSS)
is to provide general terminology, conventions, and
notation for describing behavior and data in terms of
objects and object attributes. In addition, it provides
basic services for reading object attributes, setting their
values, and for asking for an object' s contents. This
standard is intended to be referenced by other standards
which define specific objects to reduce redundancy.
2 Scope
2.1 The scope of this standard is to provide concepts,
behavior, and services common to a variety of public
objects.
2.2 Object models are common to multiple standards.
Object Services provide basic object-related definitions,
and basic services for getting object attributes and
setting attribute values, that can be used by all standards
defining public objects. These services allow basic
management of data based on objects.
2.3 The object services defined in this document may
be included in the services provided by other standards.
They may also be provided independently of such other
standards.
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 Standards
3.1 ISO Standard
1
ISO 9595 — Common Management Information
Service (CMIS)
1 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
3.2 Other Standards
James Rumbaugh, Michael Blaha, William Premerlani,
Frederick Eddy, William Lorensen, Object-Oriented
Modeling and Design, Englewood Cliffs, New Jersey:
Prentice-Hall, 1991.
NOTICE: Unless otherwise indicated, all documents
cited shall be the latest published versions.
4 Terminology
4.1 The following basic definitions are provided in a
logical order.
4.2 Definitions
4.2.1 Requirements
4.2.1.1 fundamental compliance — conformance to all
fundamental requirements for an object or service
resource.
4.2.1.2 fundamental requirements — the requirements
for information and behavior that must be satisfied for
compliance with a standard. Fundamental requirements
apply to specific areas of application, objects, or
services.
4.2.2 Objects
4.2.2.1 object
2
— an entity with a specific set of data
and behaviors. Objects may be physical or conceptual.
4.2.2.2 standardized object — a object formally
defined in SEMI standards and in compliance with the
fundamental requirements of SEMI E39 (Object
Services Standard: Concepts, Behavior, and Services).
4.2.2.3 object model — a static graphic model of
objects to show structure — the identity of objects, their
attributes and operations, and their relationships with
one another.
4.2.2.4 object type — a formal classification of a group
of similar objects. Synonym: object class. Examples:
equipment, wafer, carrier.
2 The term “object” may refer to either an object class or an instance
of a class.
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.