TECHNOLOGY OVERVIEW SERIES

PUB00026R4
PUB00026R5 APRIL 2021
DeviceNet® – What is DeviceNet?
CIP on CAN Technology DeviceNet, like other CIP Networks, follows the Open Systems
Interconnection (OSI) model, which defines a framework for
DeviceNet® has been solving manufacturing automation implementing network protocols in seven layers: physical,
applications since the mid-1990’s, and today boasts an data link, network, transport, session, presentation and
installed base numbering in the millions of nodes. DeviceNet application. Networks that follow this model define a complete
is a member of a family of networks that implements the suite of network functionality from the physical implementation
Common Industrial Protocol (CIP™) at its upper layers. through the application or user interface layer. As with all CIP
CIP encompasses a comprehensive suite of messages and Networks, DeviceNet implements CIP at the Session layer
services for a variety of manufacturing automation applications, and above while adapting CIP to the specific DeviceNet
including control, safety, security, energy, synchronization, technology at the Transport layer and below. This network
motion, configuration, diagnostics and information. As a truly architecture is shown in Figure 1.
media-independent protocol that is supported by hundreds of
vendors around the world, CIP provides users with a unified
communication architecture throughout the manufacturing CIP Security™ CIP Motion™ Motor Control Transducer I/O Other Semiconductor CIP Safety™

Common Industrial Protocol (CIP™)

Profiles Profiles Profiles Profiles Profiles Profiles Profiles Profiles
enterprise.
CIP Security™ CIP Sync™ CIP Energy™ Object Library Safety

With media independence comes the ability to choose the CIP

Objects Objects Objects (Communications, Applications, Time Synchronization) Object Library

Network best suited for each application. One of these possible Data Management Services Safety Services

choices is DeviceNet, which adapts CIP to CAN Technology. Explicit and I/O Messages and Messages

Why adapt CIP to CAN? CAN is the same network technology CIP Security™
Originator Services
for Modbus® Device
used in automotive vehicles for communication between Objects Connecting Management, Routing
Integration
(TLS, DTLS)

smart devices and has a total installed base numbering in the

billions of node. By leveraging the economies of scale in this TCP/UDP

Network Adaptations of CIP

CompoNet ControlNet DeviceNet
proven commercial technology, DeviceNet provides users with Network and Transport Network and Transport Network and Transport

the ability to distribute and manage simple devices throughout

Internet Protocol

their architecture in a cost-effective manner. Ethernet CompoNet ControlNet CAN

CSMA/CD Time Slot CTDMA CSMA/NBA

DeviceNet offers several unique advantages for manufacturing Ethernet CompoNet ControlNet DeviceNet
automation applications: Physical Layer Physical Layer Physical Layer Physical Layer

EtherNet/IP™ CompoNet™ ControlNet™ DeviceNet®

•  omprehensive producer-consumer services let you
C
simultaneously control, configure and collect data Figure 1: DeviceNet as Part of the CIP OSI Model
from intelligent devices over a single network;

•  upport for up to 64 nodes and baud rates up to 500

S The DeviceNet network infrastructure is passive, making node
kilobits per second (kbps). functionality independent of physical location and the network
itself inherently tolerant to individual lost node connections.
•  obust physical layer, designed for high noise and
R Although the network infrastructure is passive, the network
other challenging environments, provides robust cable can convey device power over the same cable with
signal transmission while providing the user with a communication messages. This feature is extremely valuable
flexible network architecture offering a range of data for devices with small physical size and power requirements,
rates — 125, 250 and 500 kbps — and trunk-line such as photo cells, where DeviceNet simplifies the number
distances up to 500 meters (125 kbps and thick of required system components and connections.
cable);
To further decrease complexity, DeviceNet systems require
•  ower (24 Vdc, 8 Amps) and signal on the same wire
P only a single point of connection for both configuration and
with the ability to remove and replace nodes under control. This is because DeviceNet supports both I/O (or
power and power taps at any point on the network; implicit) messages—those that typically contain time-critical
and control data—and explicit messages—those in which the
data field carries both protocol information and specific
•  ugged installation options include round cable that
R service requests. And, as a producer-consumer network
allows for flexible cabling topologies, including daisy- that supports multiple communication hierarchies and
chain and trunk-line, with range of connector options message prioritization, DeviceNet provides more efficient
available, including screw-terminal and hard-wired use of bandwidth than a device network based on a source-
(IP20) and mini and micro-style plugs (IP67), or flat destination model. DeviceNet systems can be configured
cable with flat trunk connectors (IP67). to operate either in a controller/device or distributed control
architecture using peer-to-peer communication.

Here’s a more in-depth look at the technology behind every

DeviceNet-compliant product.

2
The Physical Layer
DeviceNet incorporates a trunkline-dropline topology that
allows the use of separate twisted pair buses for both signal
and power distribution. The possible variants of this topology
are shown in Figure 2.

Multiple Node
Node Node Terminating Resistor Figure 3: Figure 4: Figure 5:
Trunk line
Branching Multi-Port Screw-terminal & Mini & Micro- Flat cable with
Drop Line
Node
Tap
Node
hard-wired style Pluggable flat trunk
Terminating
connectors (IP20) connectors (IP67) connectors (IP67)
Node Node
Multiple Node
Resistor Node Daisy Chain
Drop Line

Tap
Node

The Data Link Layer

Multi-Port Tap
Node Node
Drop line
Node
Node Node
Node
DeviceNet uses standard, unmodified CAN for its Data Link
Zero Length Drop Line Short Drop Line (6 m/20 ft) layer. The relatively minimal overhead required by CAN at
the Data Link layer makes DeviceNet efficient in message
Figure 2: DeviceNet Topology Options handling. Minimal network bandwidth is used to package
and transmit CIP messages over DeviceNet, and minimal
processor overhead is required by a device to parse such
Nodes can be removed or inserted with the network on, messages.
helping to reduce production downtime. Power taps can
be added at any point on the network, enabling the use of Although the CAN specification defines several types of
redundant power supplies. The trunkline current rating is 8 message frames (e.g., data, remote, overload and error),
Amps maximum, depending on cable type. DeviceNet uses primarily only the data frame. The format for
the CAN data frame is shown in Figure 6.
DeviceNet supports three possible data rates, and the user
may choose from several cable options. In general, these  
cables can be used as trunkline or as dropline, but end-to-end
network length will vary depending on the cable type selected
and the date rate used, as shown in Table 1.

Figure 6: CAN Data Frame Format

Cable Type 125 kbps 250 kbps 500 kbps Figure 6
CAN Data Frame Format
Thick Round
500 m (1,640 ft) 250 m (820 ft) 100 m (328 ft) The CAN specification defines two logical bus states called
Cable
“dominant” (logic 0) and “recessive” (logic 1). Any transmitter
Thin Round
Cable
100 m (328 ft) 100 m (328 ft) 100 m (328 ft) can drive the bus to a dominant state, while the bus can
be in the recessive state only when no transmitter is in the
Flat Cable 420 m (1,378 ft) 200 m (656 ft) 75 m (246 ft) dominant state. This is an important element of the bus
arbitration scheme employed by CAN. In addition, CAN is a
Maximum Drop “carrier sense” network, meaning that nodes will only attempt
6 m (20 ft) 6 m (20 ft) 6 m (20 ft)
Length
to transmit a message when no other nodes are transmitting.
Cumulative Drop
156 m (512 ft) 78 m (256 ft) 39 m (128 ft)
Carrier sense networks provide inherent peer-to-peer
Length connection capabilities. CAN also utilizes a non-destructive,
bit-wise arbitration mechanism to resolve the potential conflict
Table 1: DeviceNet end-to-end network distance as a function between multiple nodes accessing the bus simultaneously,
of data rate and cable type and does so with no loss of data or bandwidth.

DeviceNet supports devices with physical layer When a “Start of Frame” bit is transmitted, all receivers
implementations that are isolated or non-isolated. However, on a CAN network synchronize to the transition from the
since the DeviceNet physical layer must be optically isolated recessive to the dominant state. The CAN Identifier and the
from the rest of the device, externally powered devices (e.g., Remote Transmission Request bit (RTR2) together form
AC drive starters and solenoid valves) can share the same bus the arbitration field, which is used to facilitate media access
cable, helping to save space and reduce wiring complexity. priority. When a device transmits, it also monitors each bit
it sends by simultaneously receiving each bit transmitted in
DeviceNet provides a choice of screw-terminal or pluggable order to validate the data transmitted and to enable immediate
connector types, as shown in figures 3 through 5. detection of simultaneous transmission. If a node transmitting
a recessive bit receives a dominant bit while sending the
arbitration field, it stops transmitting. The winner of arbitration

TECHNOLOGY OVERVIEW SERIES: DEVICENET

3
PUB00026R5 ©2021 ODVA, Inc. All rights reserved.
between all nodes transmitting simultaneously is the one with In order to take full advantage of DeviceNet’s producer-
the lowest-numbered 11-bit identifier. consumer capabilities, the uniqueness of each connection ID
is strictly controlled. To achieve this goal, DeviceNet uses the
The CAN Control Field contains six bits. The content of two 11-bit CAN identifier to define the connection ID and divides
bits is fixed, while the other four are used for a “length field,” the 11-bit CAN identifier into four groups. The first three defined
which specifies the length of the forthcoming Data Field from groups contain two fields: one 6-bit field for Media Access
zero to eight bytes. Code Identifier (MAC ID) and the other for Message ID. The
combined fields define the connection ID. By design, nodes in
The CAN Data Frame is followed by the Cyclic Redundancy a DeviceNet system are responsible for managing their own
Check (CRC) field to detect frame errors as well as several identifiers. These identifiers are distributed throughout the
frame formatting delimiters. By employing several types of entire range of message priorities that are available to each
error detection and fault confinement methods—including node, regardless of their MAC ID. Through a duplicate MAC
CRC and automatic retries—that are mostly transparent to ID algorithm, the uniqueness of CAN identifiers is guaranteed
the network and that prevent a faulty node from disrupting the without the need for a central tool or record for each network.
network, CAN provides highly robust error checking and fault
confinement capabilities. IDENTIFIER BITS
HEX RANGE IDENTITY USAGE
10 9 8 7 6 5 4 3 2 1 0
Group 1 000 – 3ff Message Group 1

The Network and

0 Source MAC ID
Message ID
Group 2 400 – 5ff Message Group 2

Transport Layers
1 0 MAC ID Message
ID
Group 3 600 – 7bf Message Group 3
1 1 Message Source MAC ID
DeviceNet is a connection-based network, meaning that
ID
a relationship (i.e., connection) with a device must first Group 4 Message ID 7c0 – 7ef Message Group 4
be established in order to exchange data with that device. 1 1 1 1 1
(0-2f)
Connections are established via either an Unconnected 1 1 1 1 1 1 1 X X X X 7f0 – 7ff Invalid CAN Identifiers
Message Manager (UCMM) or a Group 2 Unconnected Port. 10 9 8 7 6 5 4 3 2 1 0
In addition, DeviceNet supports two types of messages,
Explicit and Implicit (often referred to as I/O Messages).
Figure 7: DeviceNet allocations within the 11-bit CAN Identifier
Explicit messages are used for request/response-oriented
Field.
transactions typically associated with configuration or data
collection that are not time critical, whereas Implicit messages
are used to communicate real-time I/O data. Because DeviceNet uses a device address inside the CAN
identifier field, it incorporates automatically a mechanism for
Devices may be clients, servers or both, and, in turn, clients detecting nodes with duplicate addresses. This is important
and servers may be producers, consumers or both. A typical because it is more efficient to prevent duplicate addresses
client device’s connections produce requests and consume than to locate them after they occur. Another key benefit to
responses. A typical server device’s connections consume nodes managing their identifiers is that a user can add and
requests and produce responses. DeviceNet allows several delete nodes, add additional peer-to-peer messages among
variations on this model. For example, some client and/or existing nodes at any time, or both, without having to know the
server connections that may only consume messages are existing setup. That is, no centralized record must be located
the destinations for cyclic or change-of-state messages. or reconstructed. Since nodes know which IDs are already
Similarly, some client and/or server connections may only in use, a tool must simply request that an I/O connection be
produce messages, and these connections are the sources added between the two devices, specifying priority level,
for cyclic or change-of-state messages. The use of cyclic the data path (class, instance, attribute) and the production
and change-of-state connections can substantially reduce trigger (cyclic, poll or change-of-state).
network bandwidth requirements.

Whenever communicating with a device, an Explicit

Messaging Connection is established first via the UCMM or
Group 2 Unconnected port. This explicit connection can then
be used to move information from one node to the other, or
to establish an Implicit (e.g., I/O) connection. Once an I/O
connection has been established, the 11-bit CAN identifier
field serves as the unique identifier of this data. The remainder
of the frame contains no protocol data, only application data.
When the application requires more than eight bytes of data
in a message, it is utilizes the DeviceNet fragmentation
protocol to move the data in several successive messages
or “fragments.”

4
The Upper Layers The Predefined Controller/
DeviceNet uses the Common Industrial Protocol (CIP), a Device Connection Set
strictly object-oriented protocol, at the upper layers. Each
CIP object has attributes (data), services (commands) and DeviceNet provides for an alternate, simplified communication
behaviors (reactions to events). CIP’s producer-consumer scheme based on a controller/device relationship. Called the
communication model provides more efficient use of network “Predefined Controller/Device Connection Set,” this scheme
resources than a source-destination model by allowing the simplifies both the packaging and the movement of data
exchange of application information between a sending device contained in the I/O messages most often used in control
(e.g., the producer) and many receiving devices (e.g., the applications.
consumers) without requiring data to be transmitted multiple
times by a single source to multiple destinations. In producer- Because one of DeviceNet’s key unique advantages is
consumer networks, a message is identified by its connection “power” on the network, many DeviceNet-compliant sensors
ID, not its destination address (as is the case with source- and actuators are designed to perform a predetermined
destination networks). CIP’s message structure makes it function on power-up. In this case, both the type and amount
possible for multiple nodes to consume data produced by a of data the device will produce and/or consume is also known
single source based solely on the connection ID to which the on power-up. The Predefined Controller/Device Connection
message refers. Thus, the producer-consumer model provides Set provides connection objects that are almost entirely
a clear advantage for users of CIP Networks by making efficient configured at the time the device powers-up.
use of network resources in the following ways:
After powering up the network, the only remaining step
• If a node wants to receive data, it only needs to ask necessary to begin the flow of data is for a “controller” device
for it once to consume the data each to claim ownership of this predefined connection set within its
time it is produced. “device(s).” Devices can produce data using one or more of
the message types described in Table 2. The message type
• If a second (third, fourth, etc.) node wants the same used is determined based on how the device is configured and
data, all it needs to know is the connection ID to the requirements of the application.
receive the same data simultaneously with all other
nodes. Type Description of Operation
A device configured for polled I/O will receive
"output" data from the controller in a sequential
CIP also includes “device types” for which there are “device order that is defined by the controller’s scan list
profiles.” For a given device type, the device profile will specify and will transmit its “input” data in response to
the set of CIP objects that must be implemented, configuration the controller’s poll. The controller’s polling rate
is determined by: the number of nodes in the
options and I/O data formats. This consistency in object
Polled scan list; the DeviceNet baud rate; the size of
implementation for a given device type provides another clear messages produced by the controller and each
advantage for users of CIP Networks by promoting a common node in its scan list; and the internal timing of
application interface for a given device type and interoperability the controller. For a given system configuration,
this messaging method will provide deterministic
in networks comprised of devices from multiple vendors. For
behavior. Polled I/O "output" data is unicast and
applications where unique functionality is required, it is also “input” data is multicast.
possible for a DeviceNet vendor to define additional vendor- A device configured to produce a cyclic I/O
specific objects in a DeviceNet-compliant product in order to message will produce its data at a precisely
support the functional requirements of particular applications. defined interval. This type of I/O messaging
allows each user to configure the system to
Cyclic produce data at a rate appropriate for the ap-
Seamless bridging and routing is perhaps the most significant plication. Depending on the application, cyclic
advantage for users of CIP Networks for it is this mechanism that I/O messaging can reduce the amount of traffic
most protects the user’s investment for the future. The ability to on the wire and more efficiently use the avail-
able bandwidth.
originate a message on one CIP Network, such as DeviceNet,
A device configured to produce change-of-
and then pass it to another CIP Network, such as EtherNet/IP, state (COS) messages will produce data when-
with no presentation at the Application Layer, means that users ever it changes, or at a base “heartbeat” rate.
can incorporate incremental application improvements to existing This adjustable heartbeat rate provides a way
installations and/or integrate systems with diagnostic, prognostic for the consuming device to know that the pro-
ducer is still alive and active. DeviceNet also
and/or IT applications. Seamless bridging and routing between Change-of-state
defines a user-configurable Production Inhibit
homogeneous and heterogeneous CIP Networks is enabled by a Time that limits how often COS messages are
set of objects that defines mechanisms for a device to use when produced to prevent nodes from "flooding" the
forwarding the contents of a message produced on one network bandwidth. Users can adjust these parameters
to provide optimum bandwidth utilization in a
port to another. This mechanism does not alter the contents given application scenario.
of a message during the routing process. When using this
mechanism, the user’s only responsibility is to describe the path Table 2: Device I/O message types in the DeviceNet predefined
that a given message must follow. CIP ensures that the message controller/device connection set
is handled correctly, independent of the CIP Networks involved.

TECHNOLOGY OVERVIEW SERIES: DEVICENET

5
PUB00026R5 ©2021 ODVA, Inc. All rights reserved.
Management of the DeviceNet
Technology
DeviceNet is managed by ODVA, an international association of
the world’s leading automation companies. ODVA’s DeviceNet
management responsibilities include:

• Publishing The DeviceNet Specification;

• Overseeing the process to incorporate new enhancements

to the DeviceNet Specification;

• Licensing the DeviceNet Technology to companies desiring

to make and/or sell DeviceNet-compliant products;

• Promoting industry awareness of DeviceNet and its

benefits; and

• Helping to ensure compliance of DeviceNet products

with the specification through conformance testing and
conformity reporting.

For more information about DeviceNet, CIP or ODVA, visit ODVA

at www.odva.org.

6
About ODVA
Founded in 1995, ODVA is a global association whose members
comprise the world’s leading automation companies. ODVA’s mission
is to advance open, interoperable information and communication
technologies in industrial automation. ODVA recognizes its media
independent network protocol, the Common Industrial Protocol or “CIP” –
and the network adaptations of CIP – EtherNet/IP, DeviceNet, CompoNet
and ControlNet – as its core technology and the primary common interest
of its membership. For future interoperability of production systems and
the integration of the production systems with other systems, ODVA
embraces the adoption of commercial-off-the-shelf (COTS) and standard,
unmodified Internet and Ethernet technologies as a guiding principle
wherever possible. This principle is exemplified by EtherNet/IP – the
world’s number one industrial Ethernet network. For more information
about ODVA, visit odva.org.

ODVA
Ann Arbor, Michigan, USA
TEL: +1 734-975-8840
FAX: +1 734-922-0027
WEB: www.odva.org

PUB00026R5
©1999-2021 ODVA, Inc.

TECHNOLOGY OVERVIEW SERIES: DEVICENET

7
PUB00026R5 ©2021 ODVA, Inc. All rights reserved.