semi合集-English.pdf - 第1666页
SEMI E39-0703 © SEMI 1995, 2003 8 8.3 Object Definition — An object d efinition includes an attribute definition t able describe d in Section 5.3. 8.3.1 The object that is the super-type of all public objects is called t…
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.
SEMI E39-0703 © SEMI 1995, 2003 8
8.3 Object Definition — An object definition includes
an attribute definition table described in Section 5.3.
8.3.1 The object that is the super-type of all public
objects is called the top object. The attributes and
operations of the top object, shown in Figure 1, are
fundamental requirements for all public objects. That is,
all objects shall respond to the object attributes
ObjType
and text strings, and all public objects shall
recognize and respond to the operations get attributes
and set attributes.
Figure 1
Top Object
8.3.2 Formal definition of an object shall include a
table defining the object' s public attributes. The Object
Attribute Definition table for the top object is given in
Table 1 below. It contains the two fundamental
attributes required of all public objects.
Table 1 Top Object Attribute Definition
Name Definition Access Req Form
ObjType The object type. RO Y Text
ObjID The object' s identifier. RO Y Text
8.3.3 Access refers to the ability to read and write the
value of the attribute through OSS services. An
object’s type and identifier may not be changed through
OSS services. However, it may be possible for the
service user to assign a value for the object' s identifier
at the time the object (instance) is created. This depends
on the object and the services provided.
9 Object Relationships
9.1 This section addresses relationships between
objects that affect communications, either by restricting
communications or through information concerning
relationships.
9.2 Object Hierarchy — Certain objects may be
specified as aggregation objects or as container objects
when they are defined.
9.2.1 An aggregation object is composed of other
objects called the components of the aggregation. This
is illustrated in Figure 2. Components may be of one or
more different types, or they may be of the same type.
Figure 2
Aggregation with Two Component Types
9.2.2 Container objects contain other objects, of the
same or different types, but are not made up of them.
9.2.3 Figure 3 shows two object types that are
associated with a relationship called “contains.” The
solid circle indicates that Type-1 may contain zero or
more objects of Type-2 type. An example of a common
container type is a file directory.
Figure 3
Container and Contents
9.2.4 An aggregation loses some degree of integrity if
certain of its components are missing, while a container
retains full integrity even if it has no contents. An
automobile is an aggregation of many components,
some of which are themselves aggregations. An
automobile may also have contents (driver, passengers,
belongings) which are removable and not considered as
components. Other examples of container objects
include lists, dictionaries, and libraries. A container that
has no contents is said to be empty.
9.2.5 The aggregation or container is called the
superior object and its components or contents are
called subordinate objects.
9.2.6 In addition to the relationships of “is composed
of” (roles: aggregate/component) and “contains” (roles:
container/contents), the other hierarchical relationship
that occurs naturally in factories and in control systems
is that of “supervises” (roles: supervisor/supervised).
This denotes a control relationship where the
supervised object accepts part or all of its directions
from the supervisor. The supervisor, in turn, has
responsibilities that it delegates to the supervised. The
supervisor typically will also have a relationship of “is
composed of” or “contains” with its supervised
subordinates.
SEMI E39-0703 © SEMI 1995, 2003 9
9.3 Scope and Ownership — The hierarchical
relationships of aggregations, containers, and
supervisors may at times be required for pointing to a
specific object. These relationships may be shown with
a multi-level tree structure, as shown in Figure 4.
Subordinate objects at one level may be the superior
objects at the next lower level. The superior object at
the highest level is called the root of the tree.
NOTE 1: Figure 4 is not drawn in OMT notation.
9.3.1 An owner object is an object that is an aggregate,
container, or supervisor. An owned object is an object
that is a component of, contained in, or supervised by,
an owner object.
9.3.2 Scope
7
is the concept and method of pointing to
a specific owned object through the use of sequence of
hierarchical relationships. Scope allows any particular
object (type or instance) within such a hierarchical tree
to be fully specified by providing a unique path down
this tree using a concatenation of object types and
identifiers.
Figure 4
Example of Owner Hierarchy
9.3.3 This path is used to create an object specifier that
is represented as a sequence of concatenated text strings
of the form “type:id>”, which may be repeated as
necessary to form the complete path. The character “>”
is used to terminate the object type field, and the colon
character “:” is used to terminate the identifier field.
The object specifier uniquely identifies an object within
the entire domain of objects and is able to extend the
domain within which a search for an object would
otherwise occur.
9.3.4 Formally, an object specifier is a formatted text
string of the form:
“type
1
:id
1
>...type
n
:id
n
>”
7 Scoping is used in material ISO 9595 (CMIS).
where “type
i
” and “id
i
” represent the object type and
object identifier, respectively, of the ith object instance
in the sequence, and where the ith object is owned by
the (i-1)th object and is the owner of the (i+ 1)th object.
9.3.5 Figure 5 shows an example of a typical set of
hierarchical relationships in the factory. An application
of scope might be through Cell AB, Cluster BB,
Process Module (PM) CB, to Device DB. In this
example, the object specifier for Device DB would be:
“FactoryHost:Hilda>Cell:AB>Cluster:BB>PM:CB>
Device:DB>”
9.3.6 It is generally not necessary to start with the root
object. It is sufficient to start with an object that is
owned by the communications partner. However, it is
invalid to omit a level in the hierarchy that is between
the starting object and the final object in the path.
9.3.7 Some systems may be able to guarantee the
uniqueness of object identifiers for their owned objects.
For example, equipment may be able to guarantee that
all of its owned objects have unique identifiers
regardless of type. In this case, an object’s identifier is
sufficient to point to a specific object instance. Object
type may be omitted without ambiguity, as it may be
obtained as an attribute of the specified object. The
form of the path then becomes " id
1
>id
2
>.id
n
>" . In the
previous example, this might be " AB>BB>CB>DB>" .
9.3.8 Object type may also be omitted in applications
where it may be inferred without ambiguity within a
particular context. A service that is dedicated to a
specific object type X, for example, that is always
owned only by another specific object type Y, may
specify usage for object type X. Since object type may
then be inferred from the context, object types X and Y
need not be included in a specifier for an object of type
X.
9.3.9 The terminator of the final identifier is optional.
This allows a single object identifier to be used as a
simple object specifier. As a result, however, it may be
necessary to provide string delimiters to prevent
premature termination of string parsing in the event an
identifier contains one or more embedded spaces.
9.3.10 Scope can be applied to any set of hierarchical
relationships, given a minimum set of requirements for
public objects:
• an object always knows its own type (ObjType),
• an object always knows its own identifier(s)
(including ObjID),
• an owner object knows the types of objects that are
its components and/or contents, or that it otherwise