TECHNOLOGY OVERVIEW SERIES

CIP on CAN Technology

PUB00026R4
PUB00026R4 MARCH 2016
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-1990s, and today boasts an data link, network, transport, session, presentation and
installed base numbering in the millions of nodes. DeviceNet is application. Networks that follow this model define a complete
a member of a family of networks that implements the Common suite of network functionality from the physical implementation
Industrial Protocol (CIP) at its upper layers. CIP encompasses through the application or user interface layer. As with all CIP
a comprehensive suite of messages and services for a variety Networks, DeviceNet implements CIP at the Session layer
of manufacturing automation applications, including control, and above while adapting CIP to the specific DeviceNet
safety, synchronization, motion, configuration, diagnostics technology at the Transport layer and below. This network
and information. As a truly media-independent protocol that architecture is shown in Figure 1.
is supported by hundreds of vendors around the world, CIP
provides users with a unified communication architecture
throughout the manufacturing enterprise. CIP Motion Motor Control Transducer I/O Other Semiconductor CIP Safety

Common Industrial Protocol (CIP)

Profiles Profiles Profiles Profiles Profiles Profiles Profiles

With media independence comes the ability to choose the CIP

Object Library Safety
Network best suited for each application. One of these possible (Communications, Applications, Time Synchronization) Object Library

choices is DeviceNet, which adapts CIP to CAN Technology.

Why adapt CIP to CAN? CAN is the same network technology Data Management Services Safety Services
Explicit and I/O Messages and Messages
used in automotive vehicles for communication between
smart devices and has a total installed base numbering in the Originator Services
for Modbus Device Connecting Management, Routing
billions of node. By leveraging the economies of scale in this Integration

proven commercial technology, DeviceNet provides users with

the ability to distribute and manage simple devices throughout TCP/UDP
their architecture in a cost-effective manner.

Network Adaptations of CIP

CompoNet ControlNet DeviceNet
Network and Transport Network and Transport Network and Transport
Internet Protocol
DeviceNet offers several unique advantages for manufacturing
automation applications: Ethernet CompoNet ControlNet CAN
CSMA/CD Time Slot CTDMA CSMA/NBA

C
 omprehensive producer-consumer services let you
Ethernet CompoNet ControlNet DeviceNet
simultaneously control, configure and collect data Physical Layer Physical Layer Physical Layer Physical Layer

from intelligent devices over a single network;

EtherNet/IP CompoNet ControlNet DeviceNet

S
 upport for up to 64 nodes and baud rates up to 500 Figure 1: DeviceNet as Part of the CIP OSI Model
kilobits per second (kbps).

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

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
PUB00026R4 2016 ODVA, Inc. All rights reserved.
between all nodes transmitting simultaneously is the one with In order to take full advantage of DeviceNets 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 methodsincluding node, regardless of their MAC ID. Through a duplicate MAC
CRC and automatic retriesthat 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 devices connections produce requests and consume than to locate them after they occur. Another key benefit to
responses. A typical server devices 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 Master/Slave
DeviceNet uses the Common Industrial Protocol (CIP), a 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). CIPs producer-consumer scheme based on a master/slave relationship. Called the
communication model provides more efficient use of network Predefined Master/Slave 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 DeviceNets 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). CIPs 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 Master/Slave 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 master device
for it once to consume the data each to claim ownership of this predefined connection set within its
time it is produced. slave(s). Slave 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 slave configured for polled I/O will receive
"output" data from the master device in a se-
CIP also includes device types for which there are device quential order that is defined by the master's
profiles. For a given device type, the device profile will specify scan list and will transmit its input data in re-
the set of CIP objects that must be implemented, configuration sponse to the masters poll. The master's poll-
ing rate is determined by: the number of nodes
options and I/O data formats. This consistency in object
Polled in the scan list; the DeviceNet baud rate; the
implementation for a given device type provides another clear size of messages produced by the master and
advantage for users of CIP Networks by promoting a common each node in its scan list; and the internal tim-
application interface for a given device type and interoperability ing of the master device. For a given system
configuration, this messaging method will pro-
in networks comprised of devices from multiple vendors. For
vide deterministic behavior. Polled I/O "output"
applications where unique functionality is required, it is also data is unicast and 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 users 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 users only responsibility is to describe the path Table 2: Slave I/O message types in the DeviceNet predefined
that a given message must follow. CIP ensures that the message master/slave connection set
is handled correctly, independent of the CIP Networks involved.

TECHNOLOGY OVERVIEW SERIES: DEVICENET

5
PUB00026R4 2016 ODVA, Inc. All rights reserved.
Management of the DeviceNet
Technology
DeviceNet is managed by ODVA, an international association
of the worlds leading automation companies. ODVAs
DeviceNet management responsibilities include:

Publishing The DeviceNet Specification;

O
verseeing 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;

P
 romoting 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 worlds leading automation companies. ODVAs 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. ODVAs vision is to contribute to the sustainability
and prosperity of the global community by transforming the model for
information and communication technology in the industrial ecosystem.
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 worlds 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

PUB00026R4
1999-2016 ODVA, Inc.

TECHNOLOGY OVERVIEW SERIES: DEVICENET

7
PUB00026R4 2016 ODVA, Inc. All rights reserved.