semi合集-English.pdf - 第1685页

SEMI E39-0703 © SEMI 1995, 2003 27 Figure A1-10 An Example of Ge neralization A1-3.2.1 An aggregati on object is composed of other objects called the components of the aggregation. Components may be of the sam e type as …

100%1 / 7923
SEMI E39-0703 © SEMI 1995, 2003 26
Figure A1-5
Qualified Association
A1-2.3.4 A qualified association, shown in Figure A1-
5, uses a qualifier to reference an object. Qualifiers
may be shown to specify the identifier used by one
object to associate with instances of the other object. If
Type-1 object is “Factory Host” and Type-2 object is
“Equipment,” a user-assigned “name” attribute may be
used as a qualifier for the equipment.
A1-2.3.5 Figure A1-6 illustrates a link object, where
link attributes are placed in an object box that is
attached to the association with a loop. A link object
may be used to show attributes that are dependent on
the association between instances of one object type to
instances of another type.
Figure A1-6
Link Object
A1-2.3.6 Figure A1-7 gives an example of a link object
for the association “Authorized On” between an
“Authorized User” and “Equipment.”
Figure A1-7
Example of a Link Object
A1-3 Generalization and Inheritance
A1-3.1 Figure A1-8 shows the concept of
generalization. Generalization categorizes a set of
object types and allows the abstraction of their common
features into a supertype, with refinements of the
supertype shown as subtypes. The subtype may be
thought of as a specialization of the supertype. For
example, “vehicle” is a supertype with many subtypes,
including “aircraft,” “automobile, “cart,” and “robot.”
Figure A1-8
Non-Overlapping Subtypes
A1-3.1.1 An instance of a subtype is also an instance
of its supertype. Attributes and operations of the
supertype are inherited by all the subtypes. That is, the
subtype has all of the same attributes and operations of
the supertype, and in addition it adds attributes and
operations of its own.
A1-3.1.2 The OMT notation for the generalization
(supertype/subtype) relationship is shown by a solid
triangle. White triangles indicate that the subtypes are
non-overlapping; an instance of one subtype may not be
an instance of another subtype.
A1-3.1.3 The method for a subtype of an object might
be different from that of the supertype or from a
different subtype, perhaps due to more specialized
knowledge that allowed a more efficient
implementation for the subtype. As an example, a
Geometrical Figure object type might have the
operation “draw.” The methods for subtypes of “circle”
and “rectangle” would differ, however.
A1-3.1.4 Figure A1-10 gives an example of an “agent”
as a generalization of various types of active entities
that might be found in a factory, and “equipment” as a
generalization of specific kinds of equipment.
Figure A1-9
Aggregation with Two Component Types
A1-3.2 Object Composition and Containment —
Figures A1-9 and A1-10 illustrate the diamond notation
used to show aggregation. An aggregation object is also
referred to as an assembly in object-oriented literature.
SEMI E39-0703 © SEMI 1995, 2003 27
Figure A1-10
An Example of Generalization
A1-3.2.1 An aggregation object is composed of other objects called the components of the aggregation.
Components may be of the same type as the aggregation (illustrated in Figure A1-10), or they may be of one or
more different types.
A1-3.2.2 In Figure A1-9, the “Superior” object type is composed of one or more objects of type “Subordinate-1,” of
exactly one component of object type “Subordinate-2,” and of zero or one objects of type “Subordinate-3.”
A1-3.2.3 In addition, an aggregate also may be optionally composed of other objects of the same type, as Figure
A1-10 illustrates. The “agent” in this figure is a very general supertype of a factory system. Additional subtypes of
agents, not shown in the figure, could include cells, clusters, and cluster modules. Cells, with equipment as
components, and clusters, with modules as components, are examples of types of agents that are aggregates
composed of other subtypes of agent.
NOTICE: SEMI makes no warranties or representations as to the suitability of the standard set forth herein for any
particular application. The determination of the suitability of the standard is solely the responsibility of the user.
Users are cautioned to refer to manufacturer’s instructions, product labels, product data sheets, and other relevant
literature respecting any materials mentioned herein. These standards are subject to change without notice.
The user’s attention is called to the possibility that compliance with this standard may require use of copyrighted
material or of an invention covered by patent rights. By publication of this standard, SEMI takes no position
respecting the validity of any patent rights or copyrights asserted in connection with any item mentioned in this
standard. Users of this standard are expressly advised that determination of any such patent rights or copyrights, and
the risk of infringement of such rights, are entirely their own responsibility.
Copyright by SEMI® (Semiconductor Equipment and Materials
International), 3081 Zanker Road, San Jose, CA 95134. Reproduction o
the contents in whole or in part is forbidden without express written
consent of SEMI.
SEMI E39.1-0703 © SEMI 1995, 2003 1
SEMI E39.1-0703
SECS-II PROTOCOL FOR OBJECT SERVICES STANDARD (OSS)
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 Regional Standards 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 This document maps the services and data of the
parent document to SECS-II streams and functions and
data definitions.
2 Scope
2.1 This document applies to all implementations of
Object Services that use the SECS-II message protocol
(SEMI E5).
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 Documents
SEMI E5 — SEMI Equipment Communications
Standard 2 Message Content (SECS-II)
SEMI E39 — Object Services Standard: Concepts,
Behavior, and Services
NOTICE: Unless otherwise indicated, all documents
cited shall be the latest published versions.
4 Mapping of Object Services
4.1 Table 1 shows the specific SECS-II streams and
functions that shall be used for SECS-II
implementations for the object services defined in OSS.
Table 1 Services Mapping Table
Message Name Stream, Function SECS-II Name
GetAttr.req S14,F1 GetAttr Request
GetAttr.rsp S14,F2 GetAttr Data
SetAttr.req S14,F3 SetAttr Request
SetAttr.rsp S14,F4 SetAttr Data
GetType.req S14,F5 GetType Request
GetType.rsp S14,F6 GetType Data
GetAttrName.req S14,F7 GetAttrName Request
GetAttrName.rsp S14,F8 GetAttrName Data
Create.req S14,F9 Create Object Request
Create.rsp S14,F10 Create Object Acknowledge
Delete.req S14,F11 Delete Object Request
Delete.rsp S14,F12 Delete Object Acknowledge
Attach.req S14,F13 Object Attach Request
Attach.rsp S14,F14 Object Attach Acknowledge
AttachSetAttr.req S14,F15 Attached Object Action Request
AttachSetAttr.rsp S14,F16 Attached Object Action Acknowledge
AttachSupervisedObject.req S14,F17 Supervised Object Action Request
AttachSupervisedObject.rsp S14,F18 Supervised Object Action Acknowledge
Detach.req S14,F15 Attached Object Action Request
Detach.rsp S14,F16 Attached Object Action Acknowledge
DetachSupervisedObject.req S14,F17 Supervised Object Action Request
DetachSupervisedObject.rsp S14,F18 Supervised Object Action Acknowledge
Reattach.req S14,F13 Object Attach Request