TECHNOLOGY OVERVIEW SERIES

PUB00026R5
APRIL 2021
PUB00026R4

DeviceNet® –CIP on CAN Technology

DeviceNet offers several unique advantages for manufacturing
automation applications:• omprehensive producer-consumer services let youCsimultaneously control, configure and collect datafrom intelligent devices over a single network;• upport for up to 64 nodes and baud rates up to 500
Skilobits per second (kbps).

•

 obust physical layer, designed for high noise andRother challenging environments, provides robust
signal transmission while providing the user with aflexible network architecture offering a range of data
rates — 125, 250 and 500 kbps — and trunk-line
distances up to 500 meters (125 kbps and thickcable);•

 ower (24 Vdc, 8 Amps) and signal on the same wirePwith the ability to remove and replace nodes underpower and power taps at any point on the network;and• ugged installation options include round cable thatR
allows for flexible cabling topologies, including daisychain and trunk-line, with range of connector options
available, including screw-terminal and hard-wired(IP20) and mini and micro-style plugs (IP67), or flat
cable with flat trunk connectors (IP67).

Here’s a more in-depth look at the technology behind every
DeviceNet-compliant product.

2

CIP Security™
Profiles

CIP Motion™
ProfilesMotor Control
ProfilesCIP Security™
Objects

CIP Sync™
Objects

CIP Energy™
Objects

Transducer
ProfilesI/O
ProfilesOther
ProfilesObject Library(Communications, Applications, Time Synchronization)

Data Management Services
Explicit and I/O Messages
Originator Services
for Modbus® Device
Integration

CIP Security™
Objects(TLS, DTLS)

Semiconductor
ProfilesCIP Safety™
ProfilesSafetyObject Library

Safety Services
and Messages

Connecting Management, Routing

TCP/UDP
CompoNet
Network and Transport

ControlNet
Network and Transport

DeviceNet
Network and Transport

Ethernet
CSMA/CD

CompoNet
Time Slot

ControlNet
CTDMA

CAN
CSMA/NBA

Ethernet
Physical Layer

CompoNet
Physical Layer

ControlNet
Physical Layer

DeviceNet
Physical Layer

EtherNet/IP™

CompoNet™

ControlNet™

DeviceNet®

Internet Protocol

Network Adaptations of CIP

With media independence comes the ability to choose the CIP
Network best suited for each application. One of these possible
choices is DeviceNet, which adapts CIP to CAN Technology.
Why adapt CIP to CAN? CAN is the same network technology
used in automotive vehicles for communication between
smart devices and has a total installed base numbering in thebillions of node. By leveraging the economies of scale in thisproven commercial technology, DeviceNet provides users withthe ability to distribute and manage simple devices throughout
their architecture in a cost-effective manner.

DeviceNet, like other CIP Networks, follows the Open Systems
Interconnection (OSI) model, which defines a framework for
implementing network protocols in seven layers: physical,
data link, network, transport, session, presentation andapplication. Networks that follow this model define a complete
suite of network functionality from the physical implementation
through the application or user interface layer. As with all CIP
Networks, DeviceNet implements CIP at the Session layer
and above while adapting CIP to the specific DeviceNettechnology at the Transport layer and below. This networkarchitecture is shown in Figure 1.

Common Industrial Protocol (CIP™)

DeviceNet® has been solving manufacturing automation
applications since the mid-1990’s, and today boasts an
installed base numbering in the millions of nodes. DeviceNet
is a member of a family of networks that implements theCommon Industrial Protocol (CIP™) at its upper layers.
CIP encompasses a comprehensive suite of messages andservices for a variety of manufacturing automation applications,
including control, safety, security, energy, synchronization,
motion, configuration, diagnostics and information. As a truly
media-independent protocol that is supported by hundreds ofvendors around the world, CIP provides users with a unified
communication architecture throughout the manufacturing
enterprise.

What is DeviceNet?

Figure 1: DeviceNet as Part of the CIP OSI Model

The DeviceNet network infrastructure is passive, making nodefunctionality independent of physical location and the network
itself inherently tolerant to individual lost node connections.
Although the network infrastructure is passive, the network
cable can convey device power over the same cable with
communication messages. This feature is extremely valuablefor devices with small physical size and power requirements,
such as photo cells, where DeviceNet simplifies the numberof required system components and connections.
To further decrease complexity, DeviceNet systems require
only a single point of connection for both configuration andcontrol. This is because DeviceNet supports both I/O (orimplicit) messages—those that typically contain time-criticalcontrol data—and explicit messages—those in which thedata field carries both protocol information and specificservice requests. And, as a producer-consumer networkthat supports multiple communication hierarchies andmessage prioritization, DeviceNet provides more efficientuse of bandwidth than a device network based on a sourcedestination model. DeviceNet systems can be configured
to operate either in a controller/device or distributed control
architecture using peer-to-peer communication.

The Physical Layer
DeviceNet incorporates a trunkline-dropline topology thatallows 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
BranchingDrop Line

Terminating
Resistor

Node

Node

Terminating Resistor

Trunk line

Multi-Port
Tap

Node
Node

Node
Node

Node
Tap

Node

Node

Multi-Port Tap

NodeDrop line

Node
Node

Node
Zero Length Drop LineMultiple Node
Daisy Chain
Drop Line

Node

Short Drop Line (6 m/20 ft)

Figure 2: DeviceNet Topology Options

Nodes can be removed or inserted with the network on,
helping to reduce production downtime. Power taps canbe added at any point on the network, enabling the use of
redundant power supplies. The trunkline current rating is 8
Amps maximum, depending on cable type.
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.
Cable Type125 kbps

250 kbps

500 kbps

Thick RoundCable

500 m (1,640 ft)

250 m (820 ft)

100 m (328 ft)

Thin Round
Cable

100 m (328 ft)

100 m (328 ft)

100 m (328 ft)

Flat Cable

420 m (1,378 ft)

200 m (656 ft)

75 m (246 ft)

Maximum Drop
Length6 m (20 ft)

6 m (20 ft)

6 m (20 ft)

Cumulative Drop
Length156 m (512 ft)

78 m (256 ft)

39 m (128 ft)

Table 1: DeviceNet end-to-end network distance as a functionof data rate and cable type

DeviceNet
supports
deviceswithphysicallayer
implementations that are isolated or non-isolated. However,since the DeviceNet physical layer must be optically isolated
from the rest of the device, externally powered devices (e.g.,
AC drive starters and solenoid valves) can share the same bus
cable, helping to save space and reduce wiring complexity.
DeviceNet provides a choice of screw-terminal or pluggableconnector types, as shown in figures 3 through 5.

TECHNOLOGY OVERVIEW SERIES: DEVICENET
PUB00026R5		

©2021 ODVA, Inc. All rights reserved.

Figure 3:
Screw-terminal &hard-wired
connectors (IP20)

Figure 4:
Mini & Microstyle Pluggableconnectors (IP67)

Figure 5:
Flat cable withflat trunkconnectors (IP67)

The Data Link Layer
DeviceNet uses standard, unmodified CAN for its Data Link
layer. The relatively minimal overhead required by CAN at
the Data Link layer makes DeviceNet efficient in message
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 suchmessages.
Although the CAN specification defines several types ofmessage frames (e.g., data, remote, overload and error),
DeviceNet uses primarily only the data frame. The format for
the CAN data frame is shown in Figure 6.

Figure 6: CAN Data Frame Format
Figure 6
CAN Data Frame Format

The CAN specification defines two logical bus states called“dominant” (logic 0) and “recessive” (logic 1). Any transmittercan drive the bus to a dominant state, while the bus canbe in the recessive state only when no transmitter is in thedominant state. This is an important element of the bus
arbitration scheme employed by CAN. In addition, CAN is a“carrier sense” network, meaning that nodes will only attempt
to transmit a message when no other nodes are transmitting.
Carrier sense networks provide inherent peer-to-peer
connection capabilities. CAN also utilizes a non-destructive,
bit-wise arbitration mechanism to resolve the potential conflict
between multiple nodes accessing the bus simultaneously,
and does so with no loss of data or bandwidth.
When a “Start of Frame” bit is transmitted, all receivers
on a CAN network synchronize to the transition from therecessive to the dominant state. The CAN Identifier and theRemote Transmission Request bit (RTR2) together form
the arbitration field, which is used to facilitate media accesspriority. When a device transmits, it also monitors each bit
it sends by simultaneously receiving each bit transmitted inorder to validate the data transmitted and to enable immediate
detection of simultaneous transmission. If a node transmittinga recessive bit receives a dominant bit while sending thearbitration field, it stops transmitting. The winner of arbitration3

between all nodes transmitting simultaneously is the one withthe lowest-numbered 11-bit identifier.
The CAN Control Field contains six bits. The content of two
bits is fixed, while the other four are used for a “length field,”which specifies the length of the forthcoming Data Field fromzero to eight bytes.
The CAN Data Frame is followed by the Cyclic Redundancy
Check (CRC) field to detect frame errors as well as several
frame formatting delimiters. By employing several types oferror detection and fault confinement methods—including
CRC and automatic retries—that are mostly transparent to
the network and that prevent a faulty node from disrupting the
network, CAN provides highly robust error checking and fault
confinement capabilities.

The Network andTransport Layers
DeviceNet is a connection-based network, meaning thata relationship (i.e., connection) with a device must firstbe established in order to exchange data with that device.
Connections are established via either an Unconnected
Message Manager (UCMM) or a Group 2 Unconnected Port.
In addition, DeviceNet supports two types of messages,
Explicit and Implicit (often referred to as I/O Messages).
Explicit messages are used for request/response-oriented
transactions typically associated with configuration or datacollection that are not time critical, whereas Implicit messages
are used to communicate real-time I/O data.
Devices may be clients, servers or both, and, in turn, clientsand servers may be producers, consumers or both. A typicalclient device’s connections produce requests and consume
responses. A typical server device’s connections consume
requests and produce responses. DeviceNet allows several
variations on this model. For example, some client and/or
server connections that may only consume messages are
the destinations for cyclic or change-of-state messages.
Similarly, some client and/or server connections may only
produce messages, and these connections are the sources
for cyclic or change-of-state messages. The use of cyclic
and change-of-state connections can substantially reduce
network bandwidth requirements.
Whenever communicating with a device, an Explicit
Messaging Connection is established first via the UCMM orGroup 2 Unconnected port. This explicit connection can thenbe used to move information from one node to the other, orto 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 remainderof 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

In order to take full advantage of DeviceNet’s producerconsumer capabilities, the uniqueness of each connection ID
is strictly controlled. To achieve this goal, DeviceNet uses the
11-bit CAN identifier to define the connection ID and divides
the 11-bit CAN identifier into four groups. The first three definedgroups contain two fields: one 6-bit field for Media Access
Code Identifier (MAC ID) and the other for Message ID. The
combined fields define the connection ID. By design, nodes ina DeviceNet system are responsible for managing their own
identifiers. These identifiers are distributed throughout theentire range of message priorities that are available to eachnode, regardless of their MAC ID. Through a duplicate MAC
ID algorithm, the uniqueness of CAN identifiers is guaranteed
without the need for a central tool or record for each network.
IDENTIFIER BITS
10 9 8 7 6 5 4 3 2 1 0Group 10
Source MAC ID
Message ID
Group 2
1 0
MAC ID
Message
ID
Group 31 1 Message
Source MAC ID
IDGroup 4 Message ID
1 1 1 1 1
(0-2f)
1 1 1 1 1 1 1 X X X X
10 9 8 7 6 5 4 3 2 1 0

HEX RANGEIDENTITY USAGE

000 – 3ff

Message Group 1

400 – 5ff

Message Group 2

600 – 7bf

Message Group 3

7c0 – 7ef

Message Group 4

7f0 – 7ff

Invalid CAN Identifiers

Figure 7: DeviceNet allocations within the 11-bit CAN Identifier
Field.

Because DeviceNet uses a device address inside the CAN
identifier field, it incorporates automatically a mechanism fordetecting nodes with duplicate addresses. This is importantbecause it is more efficient to prevent duplicate addresses
than to locate them after they occur. Another key benefit tonodes managing their identifiers is that a user can add anddelete nodes, add additional peer-to-peer messages among
existing nodes at any time, or both, without having to know theexisting setup. That is, no centralized record must be locatedor reconstructed. Since nodes know which IDs are alreadyin use, a tool must simply request that an I/O connection be
added between the two devices, specifying priority level,
the data path (class, instance, attribute) and the production
trigger (cyclic, poll or change-of-state).

The Upper Layers
DeviceNet uses the Common Industrial Protocol (CIP), a
strictly object-oriented protocol, at the upper layers. Each
CIP object has attributes (data), services (commands) andbehaviors (reactions to events). CIP’s producer-consumer
communication model provides more efficient use of network
resources than a source-destination model by allowing theexchange of application information between a sending device(e.g., the producer) and many receiving devices (e.g., theconsumers) without requiring data to be transmitted multiple
times by a single source to multiple destinations. In producerconsumer networks, a message is identified by its connection
ID, not its destination address (as is the case with sourcedestination networks). CIP’s message structure makes it
possible for multiple nodes to consume data produced by asingle source based solely on the connection ID to which themessage refers. Thus, the producer-consumer model provides
a clear advantage for users of CIP Networks by making efficientuse of network resources in the following ways:•If a node wants to receive data, it only needs to ask
for it once to consume the data each 			time it is produced.

•If a second (third, fourth, etc.) node wants the samedata, all it needs to know is the connection ID toreceive the same data simultaneously with all othernodes.

CIP also includes “device types” for which there are “device
profiles.” For a given device type, the device profile will specify
the set of CIP objects that must be implemented, configuration
options and I/O data formats. This consistency in object
implementation for a given device type provides another clear
advantage for users of CIP Networks by promoting a common
application interface for a given device type and interoperability
in networks comprised of devices from multiple vendors. For
applications where unique functionality is required, it is also
possible for a DeviceNet vendor to define additional vendorspecific objects in a DeviceNet-compliant product in order tosupport the functional requirements of particular applications.
Seamless bridging and routing is perhaps the most significant
advantage for users of CIP Networks for it is this mechanism thatmost protects the user’s investment for the future. The ability tooriginate a message on one CIP Network, such as DeviceNet,
and then pass it to another CIP Network, such as EtherNet/IP,
with no presentation at the Application Layer, means that users
can incorporate incremental application improvements to existing
installations and/or integrate systems with diagnostic, prognostic
and/or IT applications. Seamless bridging and routing between
homogeneous and heterogeneous CIP Networks is enabled by aset of objects that defines mechanisms for a device to use when
forwarding the contents of a message produced on one network
port to another. This mechanism does not alter the contents
of a message during the routing process. When using thismechanism, the user’s only responsibility is to describe the paththat a given message must follow. CIP ensures that the message
is handled correctly, independent of the CIP Networks involved.

TECHNOLOGY OVERVIEW SERIES: DEVICENET
PUB00026R5		

©2021 ODVA, Inc. All rights reserved.

The Predefined Controller/
Device Connection Set
DeviceNet provides for an alternate, simplified communication
scheme based on a controller/device relationship. Called the“Predefined Controller/Device Connection Set,” this scheme
simplifies both the packaging and the movement of datacontained in the I/O messages most often used in control
applications.
Because one of DeviceNet’s key unique advantages is“power” on the network, many DeviceNet-compliant sensors
and actuators are designed to perform a predeterminedfunction on power-up. In this case, both the type and amountof data the device will produce and/or consume is also known
on power-up. The Predefined Controller/Device Connection
Set provides connection objects that are almost entirely
configured at the time the device powers-up.
After powering up the network, the only remaining stepnecessary to begin the flow of data is for a “controller” device
to claim ownership of this predefined connection set within its“device(s).” Devices can produce data using one or more of
the message types described in Table 2. The message typeused is determined based on how the device is configured andthe requirements of the application.
Type

PolledCyclicChange-of-state

Description of Operation
A device configured for polled I/O will receive"output" data from the controller in a sequential
order that is defined by the controller’s scan list
and will transmit its “input” data in response to
the controller’s poll. The controller’s polling rateis determined by: the number of nodes in thescan list; the DeviceNet baud rate; the size of
messages produced by the controller and eachnode in its scan list; and the internal timing of
the controller. For a given system configuration,
this messaging method will provide deterministic
behavior. Polled I/O "output" data is unicast and“input” data is multicast.
A device configured to produce a cyclic I/Omessage will produce its data at a precisely
defined interval. This type of I/O messaging
allows each user to configure the system toproduce data at a rate appropriate for the application. Depending on the application, cyclic
I/O messaging can reduce the amount of traffic
on the wire and more efficiently use the available bandwidth.
A device configured to produce change-ofstate (COS) messages will produce data whenever it changes, or at a base “heartbeat” rate.
This adjustable heartbeat rate provides a way
for the consuming device to know that the producer is still alive and active. DeviceNet also
defines a user-configurable Production Inhibit
Time that limits how often COS messages areproduced to prevent nodes from "flooding" thebandwidth. Users can adjust these parameters
to provide optimum bandwidth utilization in agiven application scenario.

Table 2: Device I/O message types in the DeviceNet predefined
controller/device connection set

5

Management of the DeviceNet
Technology
DeviceNet is managed by ODVA, an international association of
the world’s leading automation companies. ODVA’s DeviceNetmanagement 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 productswith the specification through conformance testing andconformity reporting.
For more information about DeviceNet, CIP or ODVA, visit ODVAat www.odva.org.

6About ODVAFounded 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 interestof its membership. For future interoperability of production systems andthe 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 – theworld’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
PUB00026R5		

©2021 ODVA, Inc. All rights reserved.

7