semi合集-English.pdf - 第1970页

SEMI E54.4-0704 © SEMI 1997, 2004 5 6.9 Presentation Layer — There is no distinct presentation layer. Data types and data presentation in DeviceNet messages are specified as part of the DeviceNet object definitions and o…

100%1 / 7923
SEMI E54.4-0704 © SEMI 1997, 2004 4
5.3.5 input/output connections — connections over a
DeviceNet network that provide dedicated, special-
purpose communication paths between a producing
application and one or more consuming applications.
Application-specific I/O data moves through these
ports.
6 Communication Protocol High Level
Structure
6.1 The DeviceNet protocol is loosely based on a
three-layer architecture. These layers constitute a
collapsed form of the OSI seven-layer architecture,
mapping into the physical, data link, and application
layers of the Reference Model; however, DeviceNet
provides additional functionality (such as connection
support) commonly attributed to other OSI layers. The
high level protocol architecture is shown in Figure 3.
DN Application Layer
CAN Data Link
DN Physical Layer
Layered View of DeviceNet
Application Layer
Presentation Layer
Session Layer
Transport Layer
Network Layer
Data Link Layer
Physical Layer
OSI Reference Model
Figure 3
Layered View of DeviceNet
6.1.1 Note that Figure 3 represents a conceptual view
of the device architecture. Conforming implementations
must implement the services defined in this
specification at each layer and must appear (from the
network) to have implemented this architecture;
however, an internal modular partitioning is not
required. Implementations may sacrifice modularity in
order to achieve high performance.
6.2 The DeviceNet physical layer is fully specified in
Volume 1 of the DN Specification. Features of this
layer include Trunkline - dropline configuration,
simultaneous support for both network-powered and
self-powered devices, and selectable data rates
including at least 125k, 250k, and 500k baud. 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 is specified in Volumes 1 and 2 of
the DN Specification and provides for the definition of
DeviceNet applications as a collection of addressable
objects. Two basic categories of objects exist:
Communication Objects and Application Objects.
Communication Objects manage and provide for the
runtime exchange of messages across DeviceNet.
Application Objects implement product-specific
features and/or provide a logical interface to product-
specific information of devices on a DeviceNet
network.
6.3 In the remainder of this section, the protocol
structure is described in more detail in terms of the OSI
seven layer reference model, the object model
environment, and network management specifications.
6.4 Physical Layer — The device shall comply with the
DeviceNet physical layer specification as well as the
" Interface Guidelines for DeviceNet Devices on
Semiconductor Manufacturing Tools" which is
published as part of the DeviceNet specification. This
includes 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.4.1 Physical Layer Enhancements — This standard
supports the following physical layer enhancement to
the DeviceNet specifications:
• The transmission media, including both trunk cable
and drop cable, shall be DeviceNet Thin Cable.
Specifications on this cable and its utilization in
DeviceNet systems (e.g., maximum trunk and drop
lengths) are included in the DeviceNet
specification.
6.5 Data Link Layer — The device shall comply with
the DeviceNet Data Link Layer Specifications (i.e.,
Controller Area Network Specification: Version 2).
This includes the media access control mechanism and
the logical link control mechanism. Addressing is
currently limited to 11 bits.
6.6 Network Layer — There is no distinct network
layer.
6.7 Transport Layer — There is no distinct transport
layer. Some of the functionality of this layer is
implemented in the Application Layer. Specific
functions include: segmentation/reassembly for full
message delivery and the establishment of node-to-node
connections.
6.8 Session Layer — There is no distinct session layer.
SEMI E54.4-0704 © SEMI 1997, 2004 5
6.9 Presentation Layer — There is no distinct
presentation layer. Data types and data presentation in
DeviceNet messages are specified as part of the
DeviceNet object definitions and object attribute and
service communication protocol.
6.10 Application Layer — The device shall comply
with the DeviceNet application layer specification for
defining and addressing objects, including their
attributes and services, and enabling specified network
behavior. The device shall comply with the object
model specifications provided in the DeviceNet
specification as well as the “Interface Guidelines for
DeviceNet Devices on Semiconductor Manufacturing
Tools” component of the DeviceNet specification. In
addition, the device shall comply with the object
specifications defined in Section 7 of this document.
6.10.1 Object Models — The DeviceNet protocol
provides an object-oriented specification for creating,
defining, and addressing objects explicitly, including
their attributes and services (i.e., explicit messaging),
and creating, defining, and communicating object
attribute assemblies in an application-dependent format
(i.e., input/output messaging). The device shall comply
with the object model specifications provided in the
DeviceNet documentation. In addition, the device shall
comply with the object specifications defined in Section
7 of this document.
6.11 Network Management — The device shall comply
with the DeviceNet network management specifications
(e.g., physical layer bit rate, duplicate MAC ID
detection, master-slave, and peer-to-peer network
management). No (additional) network management
functions are specified in this document.
7 Required Object Types
7.1 The DeviceNet specification identifies and
describes objects (i.e., classes) that must exist in all
DeviceNet-compliant devices. The Common Device
Model specification additionally identifies two objects
(namely the Device Manager (DM) and Sensor
Actuator Controller (SAC) objects) that must exist in all
SEMI-compliant SAN devices. The required object
types for a SEMI-compliant SAN device, using the
network communication specification described herein,
necessarily comprise the union of the above to
requirements.
7.2 A list of required and optional object types is given
in Table 2. Note that the Sensor, Actuator, and
Controller object types are not required and are
indicated as optional in the CDM specification. These
objects are aggregated together to form a SEMI- and
DN- compliant device, as shown in Figure 4.
7.3 The mapping of the DM and SAC objects are
combined into a single object in DeviceNet called the
S-Device Supervisor (DS) object.
SEMI E54.4-0704 © SEMI 1997, 2004 6
Table 2 Required Object Types
Object
DN
Class
#*
CDM
Tag **
R
equired
by
DN *
R
equired
by
CDM **
R
equired
by NCS
Identity 01 N.A.*** Yes No Yes
MR 02 N.A. Yes No Yes
DN 03 N.A. Yes No Yes
CNX 05 N.A. Yes No Yes
DM(DS) 48 DmI0 No Yes Yes
SAC(DS) 48 SACI0 No Yes Yes
Sensor **** SenIn No No No
Actuator **** ActIn No No No
Controlle
r
**** CntIn No No No
(Other) **** N.A. No No No
* See DeviceNet specification for further information; values are
hexadecimal.
** See CDM specification for further information.
*** Not applicable.
**** Application-dependent.
7.4 An embodiment of a specific device type
represented as an aggregation of the object types listed
in Table 2, that is compliant with both the CDM
specification and the DN specification, is a candidate
for a SEMI SDM as well as a DN Device Profile.
Conversely, all SEMI SDM’s and DN Device profiles
specified for operation over a SEMI-compliant DN
network must be an aggregation of the object types
listed in Table 2 and be compliant with both the CDM
specification and the DN specification.
Device
Identit
y
(
DN
)
DeviceNet
(
DN
)
Connection
(
CNX
)
Dev. Su
p
r.
(
DS
)
Senso
r
(
CDM
,
SDMs
)
Actuato
r
(
CDM
,
SDMs
)
Controller
(
CDM
,
SDMs
)
Othe
r
(
SDMs
,
DN
)
(
A
gg
re
g
ation
)
Messa
g
e
Route
r
(
MR
)
Figure 4
Aggregation of a Compliant Device
7.5 In the following sections, the presentation to the
network of object addressing, object attributes, and
object services for each of the object types listed in
Table 2 and Figure 4 is described in detail.
7.6 Identity Object — This object provides
identification of, and general information about, the
device. The Identity Object must be present in all
DeviceNet products. As specified by DeviceNet, each
DeviceNet product shall support one (and only one)
Identity object per physical connection to the
DeviceNet communication link. Presentation of object
identity, attributes, and services to the network for this
object is described in the DeviceNet specification.
Compliance with the DeviceNet specification shall
constitute compliance with this NCS for the Identity
Object.
7.7 Message Router (MR) Object — The MR Object
provides a messaging connection point through which a
service of any object class or instance residing in the
physical device may be addressed. The MR object must
be present in all DeviceNet products. As specified by
DeviceNet, each DeviceNet product shall support one
(and only one) Message Router object per physical
connection to the DeviceNet communication link.
Presentation of object identity, attributes, and services
to the network for this object is described in the
DeviceNet specification. Compliance with the
DeviceNet specification shall constitute compliance
with this NCS for the MR Object.
7.8 DeviceNet (DN) Object — The DN Object provides
the configuration and status of a DeviceNet port. As
specified by DeviceNet, each DeviceNet product shall
support one (and only one) DN object per physical
connection to the DeviceNet communication link.
Presentation of object identity, attributes, and services
to the network for this object is described in the
DeviceNet specification. Compliance with the
DeviceNet specification shall constitute compliance
with this NCS for the DN Object.
7.9 Connection (CNX) Object — The CNX Object
provides configuration and management of DeviceNet
connections. A CNX object exists at each end of a
DeviceNet connection (point-to-point or multicast).
The CNX object handles the negotiation for connection
establishment and manages a set of timers in order to
handle cyclic traffic, connection timeout and fault
containment and recovery. Several connection
behaviors are supported including: explicit messaging,
polled, cyclic, change-of-state and multicast messaging.
7.10 S-Device Supervisor (DS) Object — The DS
object is the device component responsible for
managing and consolidating the device operation as
well as coordinating the interaction of the device with
the sensory/actuation/control environment. Each device
must support one (and only one) DS object. The DS