semi合集-English.pdf - 第1989页

SEMI E54.5-0997 © SEMI 1997, 2004 5 7.1 Embedded Object Ty pe Hierarchy — SDS classifies Embedded Objects into specific object types (classes), and these types are organized into a class inheritance hi erarchy. (For more…

100%1 / 7923
SEMI E54.5-0997 © SEMI 1997, 2004 4
Figure 3
Protocol Architecture
SDS uses a three-layer protocol stack consisting of the
physical, datalink, and application layers. The SDS
physical layer uses two twisted pair to deliver power
and data to smart devices at speeds ranging from 125
Kbps to 1 Mbps and distances up to 500 meters. At the
data link layer, the CAN specification defines a carrier
sense multiple access mechanism for media access
control that avoids collisions and sends frames reliably.
The application layer supports a concise set of services
to set and get attributes of objects, to invoke operations
on objects, and to report notifications from objects.
These services are optimized for high performance in
discrete control applications (e.g., 3 byte messages
convey digital I/O state changes). In addition, a set of
pre-defined and extensible component objects flexibly
specifies all network-visible application level device
capabilities.
6.1 Physical Layer — The device shall comply with
the SDS physical layer specifications. These include
physical signaling (levels and baud rates - detailed in
the CAN specification), transceivers, node isolation,
media topology, cable specifications, network
connectors and taps, and power considerations (load
limits, system tolerances, and power supply options).
6.2 Data Link Layer — The device shall comply with
the SDS Data Link Layer Specifications (i.e., Controller
Area Network Specification: Version 2). These include
the media access control mechanism and the logical
link control mechanism. Frame formats, interframe
spacing, and error signaling shall comply with the CAN
specifications. CAN frame identifiers shall be 11 bits in
length.
6.3 Network Layer — There is no distinct network
layer. A future extension of the SDS SEMI SAN
protocol will support inter network messaging.
6.4 Transport Layer — There is no distinct transport
layer. Specific functionality of this layer is
implemented in the Application Layer. Functions
include: segmentation and reassembly for large
message delivery.
6.5 Session Layer — There is no distinct session layer.
6.6 Presentation Layer — There is no distinct
presentation layer. Data types are specified as part of
the SDS object definitions.
6.7 Application Layer — The device shall comply with
the SDS application layer specification. This includes
application object to application object communication
mechanisms.
6.7.1 Object Models — The SDS protocol provides an
object-oriented specification for defining and
addressing objects, including their attributes, actions,
and events. The device shall comply with the object
model specifications provided in the SDS Component
Model Specification. In addition, the device shall
comply with the object specifications defined in Section
7 of this document.
6.8 Network Management — The device shall comply
with the SDS system and network management
specifications.
7 Required Object Types
The Common Device Model specification identifies the
objects that must be supported in SEMI SAN-compliant
devices. These objects are specified in Table 1 of SEMI
E54 and include the following:
a) Device Manager (DM)
b) Sensor/Actuator/Controller (SAC)
c) Sensor (S
i
)
d) Actuator (A
i
)
e) Controller (C
i
).
As specified in SEMI E54, a conforming device must
support the DM, the SAC, and one or more of the
remaining object types.
This section specifies the implementation of these
required and optional objects in the SDS object model.
SDS object types are defined for the DM and SAC
objects. Sensor, actuator, or controller objects may be
implemented using existing standard SDS object types,
or new types may be specified, depending on the
specific device model needs.
SEMI E54.5-0997 © SEMI 1997, 2004 5
7.1 Embedded Object Type Hierarchy — SDS
classifies Embedded Objects into specific object types
(classes), and these types are organized into a class
inheritance hierarchy. (For more information on
classification and inheritance, see SEMI E39 -- Object
Services Standard). Each SDS object type specifies the
details of an object’s attributes, actions, and events. The
Embedded Object (an instance of a type) is a network-
addressable entity within a logical device. The
classification identifies common characteristics and
enables reuse of object definitions. The top two levels
of that hierarchy are shown in Figure 4 below.
Figure 4
Top Levels of the SDS Embedded Object Type
Hierarchy
The SDS object types are specified in detail in the SDS
Component Modeling Specification. There are four
primary Embedded Object types in the SDS type
hierarchy. These include: I/O, IEC 1131-3 Function
Object, Function Block, and SDS Interface. In addition,
a new SEMI object type has been defined for use in
developing classes necessary for SEMI SAN-compliant
networks. Each of these object types is derived from a
common type called SDS Minimum, which defines the
minimum characteristics that are common to all SDS
Embedded Objects.
All SDS object types inherit from the SDS Minimum
object type, which provides the fundamental
characteristics of an SDS device. The other top level
SDS object types shown in Figure 4 are summarized
below.
I/O Object (Type 1) — Defines the general
characteristics of objects used for process I/O type
functions. Subtypes of this type specify input and
output objects with either analog or digital process
variables. These may be used in SAN devices as the
sensor or actuator objects.
IEC 1131-3 Function Object (Type 2) — Defines
standard IEC 1131-3 Function Objects such as counters,
timers, type conversion, bit-wise operations, character
strings, etc.
Function Block Object (Type 3) — Collections of
function objects that have a specific set of inputs and
outputs (e.g., a predefined control algorithm). These
may be used in the SAN devices as the controller
objects.
SDS Interface Object (Type 4) — Models, network
interfaces, gateways, etc.
SEMI Object (object Type 10) — Implement the
additional object types necessary for SEMI SAN-
compliant networks.
7.1.1 SEMI Objects — To implement SEMI-specific
object types, the SDS object type hierarchy is
augmented with type number 10 - SEMI object. This
type, and the types derived from it, specify the new
functionality necessary to implement this SEMI
standard. Object type 10 is defined to include the
common required attributes, services, and behaviors as
described in the SAN Common Device Model standard
SEMI E54. This definition is in terms of SDS
Attributes, Actions, and Events.
In addition, there are derived types: types 10.1
implementing the SAC object and 10.2 implementing
the Device Manager (DM) object (Figure 5). Object
instances of these types are required in the Common
Device Model document SEMI E54.
Each object type inheriting from the SEMI Object type
10 (e.g., 10.1 SAC object) automatically includes the
features of the SEMI Object. Thus, both the SAC and
the DM object have the reset, abort, and recover actions
that are defined for the SEMI Object type 10. (See
Section 7.2.) The Device Manager type augments the
SEMI Object to provide the required characteristics
over and above those specified in type 10 and SDS
minimum.
As specific device models are defined, the SAC object
type will be refined to be specific to that device. These
object types are indicated in Figure 5 as object types
SDM-1, SDM-2, etc. (examples include: Mass Flow
Controller, Particle Counter, and Capacitance
Manometer SAC objects). These object types have (at
least) the set of attributes, actions, and events inherited
from SDS Minimum, the SEMI Object type, and the
SAC object type. Additionally, each SDM-n may have
other, unique attributes, actions, and events which
implement the desired behavior of a specific device
SAC object.
SEMI E54.5-0997 © SEMI 1997, 2004 6
Figure 5
Second and Third Levels of the SEMI Object Type
Hierarchy
The optional sensor and actuator objects described in
the SEMI E54 specification may be instances of
existing SDS object types (e.g., of type I/O object in
Figure 4). In cases where a desired object type is not
available under SDS object type 1, new I/O object types
may be defined as sub-types of object type 10.3 SEMI
I/O object.
7.1.2 Example SEMI Device — For clarification
purposes, an example SEMI device is shown in Figure
6 (using Rumbaugh notation). It consists of three (or
more) objects, including a DM, SAC, and binary input
object. This is a complete and fully functional SEMI
SAN-compliant digital input device.
In Figure 6, the Device is assigned an SDS address
(e.g., 125), and each object is assigned an object
instance number. The device address may be changed
during installation. Each SDS message contains a
device address and an object instance number.
Figure 6
Example Device with Multiple Objects
7.2 SEMI Object Type 10 Definition — Table 2
formally specifies the SEMI Object (type 10). The three
sections in this table specify SDS identifiers to code the
required attributes, actions, or events. The first column
is the SDS identifier number, the unique identifier used
in SDS messaging. The second column is the SEMI
E54-specified name associated with the ID#. The third
column identifies the associated tag name (identifier)
used in SEMI E54.
Table 2 Table 2 SEMI Object Common Level
Model(Object Type 10)
Type 10 SEMI Object Common Structure and Behavior
Attributes
ID Name SEMI E54 tag
None defined.
80–144 SEMI Reserved Attribute IDs Reserve
Actions
ID Name SEMI E54 tag
80 Reset SacS1/DmS1
81 Abort SacS2/DmS1
82 Recover SacS3/DmS3
83–95 SEMI Reserved Action IDs Reserve
Events
ID Name SEMI E54 tag
None defined.
80–95 SEMI Reserved Event IDs Reserve
There are no attributes that are currently identified in
SEMI E54 that are common to all SEMI objects. As a
result, there are no attributes defined in the table.
However, 64 attribute IDs have been reserved for use in
other sub-types derived from type 10 in this document
and in future revisions of this document.
SEMI E54 defines three service requests (reset, abort,
and recover) that are common to the Device Manager
and the SAC objects. These service requests are
implemented as specific SDS Actions. Each service is
mapped to a designated SDS action in Table 2. The
actions are identified as ID# 80, 81, and 82
respectively. Additional action identifiers are reserved
for use in sub-types of this type and for future use.
Not explicitly shown as Actions are the SEMI E54 Get
and Set Attribute services. The equivalent behavior is
provided by the SDS Read and Write Attribute services
that are implicit for every attribute.
The execution of a service request may cause a change
in the object’s state variable. When a device receives an
SDS action message indicating a service request, the
object transitions to the appropriate state, after which an
SDS response message is transmitted to the service