semi合集-English.pdf - 第1668页
SEMI E39-0703 © SEMI 1995, 2003 10 supervises, and is able to determine their iden tifiers (see GetType, Section 11.6), • an owner object is able to determin e the types and identifiers of its owned objects. Figure 5 Hie…
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
SEMI E39-0703 © SEMI 1995, 2003 10
supervises, and is able to determine their identifiers
(see GetType, Section 11.6),
• an owner object is able to determine the types and
identifiers of its owned objects.
Figure 5
Hierarchical Relationships in the Factory
9.4 Multiple Inheritance Hierarchy — Multiple
hierarchical inheritance may be required as an optional
capability for pointing to a specific object that provides
the same services from the inherited objects. Usually,
inherited services are implemented by the domain
object such that specifying “overrides” of attributes or
services from inherited objects is not required.
Sometimes the capability to override specified
attributes and services from inherited object is
necessary to resolve duplicated attribute names or
services or to allow duplicated names in user extended
objects.
9.4.1 If Andy an object TypeA inherits from object
TypeB and TypeC and a service requestor is focusing
services or attributes of the object TypeB rather than
those with the same name in the object TypeC, the
following text string form could specify the focused
part of the object Andy:
TypeA@TypeB:Andy
9.4.2 If any names of service and/or attribute that
TypeB provides are the same as those provided by
TypeA or TypeC, then, the object Andy will have to be
specified with the complete explanation from the
supplier as how the object handles the exception and
the differences from the original attribute or services.
So, the above expression is the same as “TypeA:Andy”
without notes to describe difference.
10 Additional Operations
10.1 This section defines operations that are common
to many types of public objects but are not required for
all types of public objects. These operations are not
required for OSS compliance. However, they may be
required for support of specific object types defined by
other standards that use OSS services.
10.2 Create and Delete — Creation and deletion are
optional services for object lifecycle management.
Object definitions may specify conditions under which
the services are supported. Objects may be created
and/or deleted in other ways. For example, the creation
and deletion of certain types of persistent objects may
be outside of the scope of OSS services, while transient
objects may be created and/or deleted automatically by
their owners as the result of other activities.
10.2.1 Create — The create operation creates an
instance of an object type.
10.2.1.1 Initial settings for one or more attributes may
be specified by the service user. Initial settings may be
required, prohibited, or optional, depending upon the
specific object type. The ability to set attribute values
through the create operation shall be clearly identified
as part of the object definition for those objects
supporting the create operation. For example, the ability
to set the value of the object identifier ObjID
may be
required, optional, or prohibited, depending upon the
type of object.
10.2.1.2 The object definition may also specify
attributes of the new object instantiation that are
returned to the service user by the service provider.
10.2.1.3 A request to create an object is invalid if it
does not provide all required attribute settings, if it
attempts to set prohibited attributes, or if it provides
values invalid for a given attribute.
10.2.1.4 The definitions of certain objects may specify
that the delete service only be provided to, or under the
authority of, the service user that requested the original
create operation. In this case, a private attribute (that is,
an attribute not accessible through services defined in
Section 11) named Delete Token
shall return a unique
integer as an attribute of the new object. This attribute
is then used in a subsequent request to delete the object.
The service user may delegate this token at its own
discretion.
10.2.1.5 The create operation is invoked by the service
Create sent to the owner that is to instantiate the
specified object. In order for the Create service to be
accepted if no owner for the object to be created is
defined in the target entity or if it is physically outside
of the domain of the entity; the object specifier shall
define the owner as “ ” (an empty string). If the entity
SEMI E39-0703 © SEMI 1995, 2003 11
is just the equipment rather than a component of the
equipment; the owner may be defined as“Equipment”
even if no such object is defined.
10.2.2 Delete — The delete operation is the inverse of
the create operation. Individual object types may
restrict deletion based on well-defined set of criteria.
For example, the definition of a type of container may
specify that a container may only be deleted when it is
empty.
10.2.2.1 If an object to be deleted requires the authority
of the service user that invoked the original create
operation, then the Delete Token
attribute of the target
object shall be provided by the user of the delete
service.
10.2.2.2 A request to delete an object is invalid if it
does not provide all required attribute settings or if it
provides values invalid for a given attribute.
10.2.2.3 The delete operation is invoked by the service
Delete sent to the object to be deleted.
10.3 Attachment — When an object receives a remote
request for an operation, it may be unable to identify
the requestor. At the same time, it may be necessary for
an object to determine if certain messages were sent by
its supervisor. This conflict is resolved by formalizing
the relationship between a supervised object and its
supervisor.
10.3.1 Attachment is a dynamic behavioral binding
between two objects in a hierarchical relationship
where it is important that the attached (supervised)
object be able to differentiate certain service requests
made by its supervisor from other requests. An attached
object has exactly one supervisor, as illustrated in
Figure 6.
10.3.2 An attached object may be detached from its
current supervisor, or it may be reattached to a different
supervisor. The latter operation is used when the
previous supervisor has become damaged and is not
intended as a general method for moving the object’s
attachment, as the former supervisor is not notified of
the change.
10.3.3 Attach — When sent to an unattached object,
the attach operation creates a logical connection
between the object and a supervisor. The object that is
being attached creates a unique, private, non-zero
numeric value, called an attach token. The attach token
is treated as an attribute named AttachToken
. It is a
private attribute of the attached object, not visible
through basic OSS services (see Section 11).
10.3.3.1 When an object is first created, it is
unattached, and the value of its attach token is set to a
default value of zero. An object is attached to another
object as a formal relationship. The operation of attach
generates the attach token, which is returned to the
service user. The supervisor uses this token in
subsequent critical service requests to identify itself to
the attached object.
10.3.3.2 The attach operation also may accept settings
for one or more attributes of the attached object, as
defined for the attached object type. This allows the
supervisor to provide values for attributes that are
otherwise regarded as read-only values and cannot be
set through the SetAttr service defined in Section 11.
An example of an attribute value that it is often
desirable to access in this way is the object specifier of
the supervisor.
10.3.3.3 Requests to attach an object that attempt to set
attributes shall be denied unless the attributes are
among those accessible to the supervisor and all
specified settings represent valid values of those
attributes. The object type and identifier shall not be
changed by the supervisor.
10.3.3.4 An attached object is owned by its supervisor.
10.3.3.5 The attach operation is invoked by the mes-
sage service Attach by an intended supervisor. Requests
to attach an already attached object shall be denied.
Figure 6
The Attachment Relationship