semi合集-English.pdf - 第1661页

SEMI E39-0703 © SEMI 1995, 2003 3 SEMI E39-0703 OBJECT SERVICES STANDARD: CONCEPTS, BEHAVIOR, AND SERVICES This standard was technically approved by the Globa l Informat ion & Control Committee and is the direct resp…

100%1 / 7923
SEMI E39-0703 © SEMI 1995, 2003 2
13.3 Determine All Objects of a Specific Type and
with Specific Characteristics
13.4 Determine Specific Attributes of a Specific
Object Instance
13.5 Determine Types of Subordinate Objects
13.6 Determine Names of Attributes of Sub-
ordinate Objects
14 Requirements for Compliance
14.2 Fundamental Requirements
14.3 Additional Capabilities
14.3.1 Filters
14.3.2 Owner Objects
14.3.3 Multiple Inheritance Hierarchy
APPENDIX 1
A1-1 Overview of Object Terminology
A1-2 Object Modeling Technique (OMT) Notation
A1-2.1 Basic Notation
A1-2.2 Associations
A1-3 Generalization and Inheritance
A1-3.1 Object Composition and Containment
LIST OF TABLES
Table 1 Top Object Attribute Definition
Table 2 Object Services
Table 3 Object Services Parameter Dictionary
Table 4 GetAttr Service
Table 5 SetAttr Service
Table 6 GetType Service
Table 7 GetAttrName Service
Table 8 Additional Object Services
Table 9 Additional Object Services Parameter
Dictionary
Table 10 Create Service
Table 11 Delete Service
Table 12 Attach Service
Table 13 AttachSetAttr Service
Table 14 Detach Service
Table 15 Reattach Service
Table 16 AttachSupervisedObject Service
Table 17 DetachSupervisedObject Service
Table 18 ObjectAction Service
Table 19 ObjectActionCompletion Notification
Table 20 GetServiceNames Service
Table 21 GetServiceParameters
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.