DeviceNet of Things
Use Cases,
Value Proposition andStatus of Specification
John Caspers
Principal Firmware Engineer
Rockwell Automation
Presented at the ODVA2017 Industry Conference & 18th Annual Meeting
February 21-23, 2017
Palm Harbor, Florida, USA
Abstract
This paper introduces the key technical concepts associated with the specification enhancements
proposed for Volume 3 (DevicNet) of the CIP Specification related to “DeviceNet of Things” SIG work. It
includes discussions around the following topics:How DeviceNet will be enhanced as an in-panel cabling and communication system solution.
Connection methods and ease of use will be improved without posing business or compatibility
risk to those already applying DeviceNet.
An overview of the new “DeviceNet or Things” specification enhancement set that builds on theexisting DeviceNet specification, including:
1. The proposed in-cabinet cabling and connector solution.
2. Support for the discovery and presentation of the physical topology of network nodes basedon their relative geographical position on the network.
3. How network geographical information will be provided to remote clients when a DeviceNet ofThings network is implemented as a subnet to other CIP networks such as EtherNet/IP.
4. How simplified network commissioning will be performed by remote client tools and/or CIP
Routers
5. How the system will facilitate the development of low cost communication interfaces fordevices with extremely cost sensitive bills of materials.
6. How the system will support the automatic replacement of defective nodes with compatible
nodes of the same type during full system operation, and how “geographic device keying” will
help facilitate this.
7. How a new “Power Tap” architecture will allow commercial off the shelf power supplies to be
used in DeviceNet of Things systems.
8. How “Smart Taps” and “Smart Terminators” will provide improved network diagnostic
capabilities in a DeviceNet of Things system.
9. How “Smart Drops” can be developed to allow existing DeviceNet nodes to work in a
DeviceNet of Things system.



How the DeviceNet of Things will help pave the way for future adoption of EtherNet/IP as
Ethernet costs continue to decline.

2017 ODVA Industry Conference

1©2017 ODVA, Inc.

Keywords
DoT - DeviceNet of Things
Smart Tap
Smart Terminator
Smart Drop
Nodal Geography
Actual Nodal Geography
Reference Geography
Network Power
Select Line
Select Line Protocol
Group 5 Messaging
IDC - Insulation Displacement Connector
Device Commissioning
Network Commissioning
Definition of terms
The terms “Switched Power” and “Control Power” are used interchangeably throughout this paper.
Nodal Geography is defined for the DeviceNet of Things as an ordered set of identity object device keys
for all nodes on a network.
Device Commissioning for a traditional DeviceNet network is the setting of the MAC ID and Baud Rate forthe device.
Device Commissioning for a DeviceNet of Things network is the setting of the MAC ID for the device
since the Baud Rate is fixed at 500 kBaud for the DeviceNet of Things.
Network Commissioning is the process of commissioning all devices on a network.

2017 ODVA Industry Conference2©2017 ODVA, Inc.

Introduction
The increased popularity of EtherNet/IP and the “Internet of Things” movement establishes a basis forinnovation of new smart “Things” in the automation world. However, the costs associated with deploying
EtherNet/IP prevent it from being successfully deployed on many low end “Things” such as contactors
and push buttons. Enhancing DeviceNet as an in-panel cabling and communication solution for low end
devices would:

Lower the cost of deployment below the levels provided by DeviceNet today.
Provide greater information delivery capabilities over hard-wired solutions.
Enhanced ease-of-use over existing networked solutions (including DeviceNet).
Simplify physical/mechanical connection methods leading to lower panel build costs.

Since DeviceNet and EtherNet/IP share the CIP protocol at the application level, DeviceNet of Thingsenhancements may also help pave the way for future adoption of EtherNet/IP as Ethernet costs continue
to decline.
This paper provides an overview of a new “DeviceNet or Things” specification enhancement set thatbuilds on the existing DeviceNet specification.
Customer Requirements for the DeviceNet of Things
Extensive customer listening sessions resulted in the following key requirements for a DeviceNet ofThings system:
It must be Functional:
 It must simplify in-cabinet wiring for panel builders.
 It must deliver both Network Power to power device electronics and Switched (Control) Power tofacilitate the actuation of Contactors and Relays.
 It must support Non-Safety and Safety devices on the same wire.
It must be Simple to use: It must use a single easy to use media connector.
 It must include a simple (or no) network commissioning methodology.
 It must eliminate the need for media trunk and drop distance calculations.
It must be Economical It must use low cost media.
 It must allow for a reduction in price and size of typical DeviceNet products.
 It must allow the use of commercial off-the-shelf power supplies.
 It must result in a lower “total cost of ownership” than hard wired solutions.

2017 ODVA Industry Conference

3©2017 ODVA, Inc.

To satisfy these requirements, Volume 3 (DeviceNet Adaptation of CIP) will be enhanced as follows: New in-cabinet media and connector will be specified to simplify in-panel wiring and deliver both
Network power and Control power. The new media introduction will also address the need tosimplifying cable trunk and drop lengths calculations.
 Miswiring protection circuitry will be removed from the physical layer specification, reducing
component cost and board real estate. Connector and cable keying will rend it unnecessary.
 A new power tap architecture will be defined and will include Network and Switched power taps
for use with standard off-the-shelf DC power supplies.
 New device commissioning and device replacement methods will be defined to simplify the nodecommissioning and replacement process, including new network topology discovery, storage anddelivery mechanisms.
 The baud rate for the network will be fixed at 500Kbaud.
 New network master functionality and restrictions will be introduced.
 EtherNet/IP to DeviceNet routing enhancements will allow a more consistent user experience inmixed EtherNet/IP / DeviceNet systems.
Volume 1 (Common Industrial Protocol) will also be enhanced as follows: New device profiles will be defined as the “DeviceNet of Things” drives communications
capabilities into simpler classes of devices such as push buttons and relays.
Compatibility with existing DeviceNet products will be facilitated. New “Smart Drops” will allow existing
DeviceNet products to participate in the new network topology discovery and delivery mechanisms.
DeviceNet of Things MediaThe figure below depicts the signals that will be conducted in the DeviceNet of Things media. Note that
the Select line needs to be broken into “Select In” and “Select Out” lines that connect to separate
microprocessor pins. This facilitates the passing of simple Select line messages from the “Select Out” pinof one node, to the “Select In” pin of a geographically adjacent node. In the figure below, this facilitates
the passing of Select line messages from left to right on the network. Messages on the Select line may
be implemented without the use of a peripheral such as a UART. They can easily be clocked out the“Select Out” pin, essentially implementing a shift register, clocking one bit at a time. The “Select In” pin of
the adjacent node receives the clocked messages.
Figure 1: DeviceNet of Things Signals

Node 1

Node 2

uProcessor
In

Node 3uProcessor
OutIn

uProcessor
Out

In

Out

SelectNetwork +Network –
CAN +
CAN –
Control +Control –Note that the CAN+, CAN-, Network+ and Network- conductors are the same as in currently available
DeviceNet media. The new Control+ and Control- lines will be used for device actuation in devices suchas contactors and relays. This is necessary since the actuation of these devices can be electrically noisy
and should be isolated from the Network power which is generally used to power device electronics.

2017 ODVA Industry Conference

4©2017 ODVA, Inc.

A new 7 wire ribbon cable will be specified. Network topology will be restricted to a linear topology only.
The maximum length of the network will be 50 meters. This will allow vendors to sell 50 meter spools ofribbon cable, and when the 50 meter spool is used up, the user will know that he must start a new
network. No “trunk and drop” calculations will be required to effectively deploy the network. The ribbon
cable will be “keyed” for use with a new “Insulation Displacement Connector” (IDC). The ribbon
cable/connector keying will insure that the cable is always attached to the ribbon cable in the correctorientation. Figure 2 below shows an initial concept of what the media and connector might look like.

Figure 2: DeviceNet of Things Preliminary Media Concept

Select line is cut
by stud. Separate
connections for
Select In and
Select Out are
madeFemale connection mateswith DoT device

Note that the yellow “Select” line is cut and individual “Select In” and “Select Out” pins are available at thedevice connector (represented in purple in the middle diagram).
Simplifying DeviceNet of Things Network Commissioning
Node commissioning in traditional DeviceNet systems (the setting of the MAC ID and Baud Rate) is
inconsistent, time consuming and susceptible to mistakes. In a recent “Voice of Customer” survey, nodecommissioning difficulties and resulting network fault conditions were one of the most often mentioned
dislikes about traditional DeviceNet. (Note that other common dislikes cited include the complexity ofDeviceNet scanner mapping and the complexity of media selection). What users want is simplicity whenit comes to commissioning their network.
To prevent baud rate mismatches, the baud rate for the DeviceNet of Things will be fixed at 500 kBaud.
The topology of DeviceNet of Things networks will be exclusively linear. The simplicity of the topology willallow DeviceNet of Things systems to determine the linear Nodal Geography of the network. This willallow a user to commission their network with respect to a known Nodal Geography. To facilitate this, a
new DeviceNet of Things Link Object and a new DeviceNet of Things Commissioning Object will be
introduced into the DeviceNet specification. These new objects will control some system behaviors byusing the Select line to throttle system level service delivery sequencing for the network. Select line
system level service delivery will always be sequential from “Select Out” to “Select In” of the adjacentnode (aka “left to right” as would be the delivery direction in Figure 1 above).

2017 ODVA Industry Conference

5©2017 ODVA, Inc.

In Master/Slave DeviceNet of Things systems, it will be required to geographically place any network
master as the “left-most” node on the wire as shown in Figure 3 below. Only a single network master willbe allowed, and in Master Slave DeviceNet of Things systems, the network master’s MAC ID will be fixedat address 0.
Figure 3: Simple Master/Slave DeviceNet of Things Network
Network Master
MAC ID 0
4 5 6 71

8

2 3
RelaysStarters

9

PushButtons

To capture the network geography, the leftmost node (the network master) initiates a Network
Geographic Discovery sequence. The master tells the node to its right (position 1 on the network) to
produce relevant information describing itself and its state on its CAN lines. This is done by sending acoded “Geography Request” service on the master’s “Select Out” pin. When the node to the master’sright (position 1) receives the coded request message, it produces the relevant information on its CAN
lines, and sends the same Select line coded Geography Request command on its “Select Out” pin. The
CAN message contents are consumed by the master and stored in an attribute of a new DeviceNet ofThings Commissioning Object. This process continues until all nodes on the network have produced theirrelevant geography information messages on their CAN lines, and the DeviceNet of Things
Commissioning Object has captured the Nodal Geography.
Relevant Nodal Geography information is reported by each network node in 2 new Group 5 CAN
messages; Device Key messages and Offline Status messages. Figure 4 illustrates the DeviceNet ofThings use of the CAN Identifier Fields and in particular the CAN Identifiers reserved for the new Group 5:
Figure 4: DeviceNet of Things Use of the CAN Identifier Fields – The New Group 5

10
0
1
1
1
1
1
10

IDENTIFIER BITS
9
8
7
6
5
4
3
2
1
0
Group 1 Message
Source MAC ID
IDGroup 20
MAC ID
Message ID
Group 3
1
Source MAC ID
Message ID
Group 4 Message ID
1
1
1
1(0 – 2f)
Group 5
1
1
1
1
0
1
1
Message ID
1
1
1
1
1
1
1
X
X
X
9
8
7
6
5
4
3
2
1
0

HEX
RANGE

IDENTITY USAGE

000-3ff

Message Group 1

400-5ff

Message Group 2

600-7bf

Message Group 37c0-7ef

Message Group 4

7f0-7f7

Message Group 5

7f8-7ff

Invalid CAN Identifiers

Production of the new Group 5 messages is allowed even when a device is in the “Communication
Faulted” state, i.e. it has failed the Duplicate MAC ID test. This allows the user to place all nodes on the
network in their “out of the box” configuration, and still determine the network Nodal Geography. The
Group 5 messages, triggered by the reception of the Select line Geography Request service, areconsumed by network masters or network commissioning tools that have implemented the DeviceNet ofThings Commissioning Object as they are produced from left to right, allowing the master orcommissioning tool to determine and report the nodal geography of the network.

2017 ODVA Industry Conference

6©2017 ODVA, Inc.

Once the Nodal Geography has been identified, a network commissioning tool can present the user withnumerous network commissioning options using the existing node commissioning services provided bytraditional DeviceNet. These options could include (but are not limited to): Set all MAC ID addresses sequentially, starting at a specified MAC ID number.
 Specify a starting MAC ID address for a group of nodes.
 Specify the MAC ID address of each node individually.
Group 5 “Device Key” messages contain the following information:
Figure 5: Group 5 Device Key Message Format
Byte
7
6
5
4
3
2
0
Vendor ID (low byte)
1
Vendor ID (high byte)
2
Device Type (low byte)
3
Device Type (high byte)
4
Product Code (low byte)
5
Product Code (high byte)
6
Major Revision
7
Minor Revision

10Group 5 “Offline Status” messages contain the following information:
Figure 6: Group 5 Offline Status Message Format
Byte
7
6
5
4
3
2
1
0
MAC ID1
Duplicate MAC ID Faulted Status
2
Serial Number (low byte)
3
Serial Number (byte 1)
4
Serial Number (byte 2)
5
Serial Number (high byte)

0

Details on how the information in the above Group 5 messages is formatted, stored and reported in
attributes of the DeviceNet of Things Commissioning Object are described in the description of the object
later in this document.
Select Line Protocol Basics
All DeviceNet of Things devices shall support the Select line message protocol. Figure 1 shows how the
Select line connections are made in a DoT system to facilitate “Select Out” to “Select In” message
delivery.
At startup, immediately after initialization, DeviceNet of Things nodes set the “Select Out” pin low,indicating to the adjacent “Select In” partner node that no system level Select line service is currently
being delivered. When a message is received on the “Select In” pin, the device services the messages,
and after processing of the message is complete and any actions specified in the command have been
executed, the Select line message is retransmitted on the “Select Out” pin of the device, relaying themessage to the next node on the network.

2017 ODVA Industry Conference

7©2017 ODVA, Inc.

The following generic packet format is transmitted in a bitwise serial fashion over the Select Out pin (withthe Sync Bit transmitted first):
Figure 7: Select Line Packet Format
Bit

15

14

13

| Validation

12
0

11
0

10
0

9
8
7
0
0
0
Reserved

|

6
0

5
0

4
|

3

2

Command

1
0
|

0
1
|

|

Reserved
Sync Bit

Figure 8: Select Line Packet Bit Fields
Bit

Field

Description0

Sync Bit

This bit signals the neighboring node that a command is beingtransmitted.

1

Reserved

Reserved for future use and shall be 0

2-4

CommandCommand issued.

5 - 12

Reserved

Reserved for future use and shall be 0

13 - 15

Validation

3-bit Validation = inverse of remainder of division of 12-bit quantity ofReserved/Command/Reserved fields (bits 1 – 12) by 8.

Bit timing for messages on the Select line is 3 ms per bit. Bits are left-shifted onto the wire by thetransmitting node. The received (sampled) message is disqualified and ignored if it fails the Validation
test.
Figure 9: Select Line Message Timing
Reserved(0)Command

3

9

Sync

Time (ms) 0

612

Validation

Reserved
(0)

15

18

21

24

27

30

33

36

39

42

45

48

51

One way to easily support the Select line message transmission and reception is to use a 1ms timer
interrupt within whose Interrupt Service Routine (ISR) any transmission or reception of bits via the SelectOut and Select In line takes place. Since a node’s timer ISR can be up to 1ms out of phase with its
neighbor’s, the following synchronization scheme can be used. Each bit is transmitted 3 times in theInterrupt Service Routine, resulting in each bit having 3ms on the wire. When a node first detects that apacket is being transmitted by its neighbor (by sensing a high level on the Select In pin), it waits for the
next interrupt and then begins the process of storing 16 bits received every third interrupt. Thisguarantees that the value read will be within the middle third of each bit’s transmission time. After all 16
bits have been sampled and stored, the Validation field is verified.

2017 ODVA Industry Conference

8©2017 ODVA, Inc.

Three Typical DeviceNet of Things Deployment Models and the DeviceNet of Things
Commissioning Object
A new “DeviceNet of Things Commissioning Object” will be provided to initiate Select line services for a
DeviceNet of Things network. It will also be used to capture, store and report the Nodal Geography of a
network, and to facilitate node commissioning for a DeviceNet of Things network. Note that in a DoT
network, “commissioning” is defined as the setting of MAC ID addresses for the nodes in a network. The
DeviceNet of Things Commissioning Object may be implemented in a CIP Router device in a DeviceNetof Things subnet system to allow a commissioning tool to reside on the other side of the Router from thesubnet. This configuration is shown in Figure 10 below.
Figure 10: DeviceNet of Things as a Subnet of EtherNet/IP

DoT Commissioning Tool
EtherNet/IP Network

SwitchCIP Router with DoT
Commissioning Object(Node 0 on DoT network)

DeviceNet of Things
Network

The DeviceNet of Things Commissioning Object may also be implemented in a controller that resides
directly on a DeviceNet of Things network as shown in figure 11 below:
Figure 11: DeviceNet of Things in a Traditional Master/Slave Single Controller System
Controller withDoT Commissioning Object(Node 0)DoT Commissioning Tool

DeviceNet of Things
Network2017 ODVA Industry Conference

9©2017 ODVA, Inc.

The DeviceNet of Things Commissioning Object may also be implemented in a commissioning tool that ismeant to reside directly on a DeviceNet of Things Publish/Subscribe network as shown in figure 12
below:
Figure 12: DeviceNet of Things in a Pure Publish/Subscribe Network
DoT Commissioning Tool
(Node 0)DeviceNet of Things
Network
The object contains instance attributes to capture and report an “Actual Nodal Geography” for theDeviceNet of Things network. In the case where the DoT Commissioning Object resides in a CIP router,
the Actual Nodal Geography can be retrieved from the CIP router by a commissioning tool on the main
network (for example, the EtherNet/IP network in figure 10 above). In the case where the DoTCommissioning Object resides in a controller, the Actual Nodal Geography can be retrieved from thecontroller by a commissioning tool on the DoT Network (as shown in figure 11 above). In the case where
the DoT Commissioning Object resides in the commissioning tool, the Actual Nodal Geography can be
discovered by the tool directly (as shown in figure 12).

The process of capturing an Actual Nodal Geography is requested by invoking the DoT Commissioning
Object “Network_Geography_Request” service. This service triggers the object to use the Select linefunction to sequentially trigger the production of node identity, status and geography information(heretofore referred to as “geography information”) on the CAN lines of all DeviceNet of Things nodes.
This information is consumed by the device that triggered the Select line service. The consumed Nodal
Geography is then stored in the “Actual Geography” instance attributes of this object. The Actual
Geography information is “read-only”.
The DoT Commissioning Object also contains instance attributes to store a “Reference” or “Desired”
Nodal Geography for a DeviceNet of Things network. The “Reference Geography” information may bedelivered to the “Reference Geography” attributes by writing the desired information to individual
attributes explicitly. The “Reference Geography” may also be determined and stored by first invoking a“Network_Geography_Request” service to determine the Actual Nodal Geography, and then transferringthe “Actual Geography” attribute data to the “Reference Geography” attributes by invoking the“Geography_Sync_Request” service. This service copies all of the information in the “Actual Geography”
attributes into the “Reference Geography” attributes of this object. The Reference Geography informationis stored non-volatilely.
Figure 13 below summarizes the instance attributes of the DoT Commissioning Object.

2017 ODVA Industry Conference

10©2017 ODVA, Inc.

Figure 13: DeviceNet of Things Commissioning Object Instance Attributes
Attribute
ID

Need in
Implementation

AccessRule

NV

1

Required

Get

V

Name

StatusData Type

WORD

Description of Attribute

Status of the object
Bit 0 = Reference Data Ready
Bit 1 = Actual Data Ready
Bit 2 = Geography Mismatch
Bits 3-15 = Reserved

2

RequiredSet

NV

Number of Nodes in
USINT
Reference Geography

Number of nodes in the stored reference
geography for the network

3

Required

Set

NV

Reference DoTSTRUCT
Commissioning Object
Node

Structure describibng the identity of the
expected device at MAC ID 0

4

Required

Set

NV

Reference First
Position

STRUCT

Reference geography information for first
node (position 1) on network

5

Required

Set

NV

Reference Second
Position

STRUCT

Reference geography information for second
node (position 2) on network

66

Required

Set

NV

Reference Sixtythird
Position

STRUCT

Reference Geography information for 63rd
node (position 63) on network

99

RequiredSet

NV

Auto Apply Reference
Geography

BOOL

Enables the Auto-Commissioning of DoT
network devices in a System based on the
Reference Geography.

182

Required

Get

V

Actual Number of
Network Nodes

UINT

Actual number of Nodes on the network

183

Required

Get

V

Actual This NodeUINT

Actual geography information for this node.

184

Required

Get

V

Actual First Position

STRUCT

Actual geography information for first node(position 1) on network

185

Required

Get

V

Actual Second
Position

STRUCT

Actual geography information for second node(position 2) on network

Required

Get

V

Actual Sixtythird
Position

STRUCT

Actual geography information for 63rd node(position 63) on network

…

…
246

Attributes 2-66 are used to store Reference Geography information. Attributes 182-246 are used to store
Actual Geography information.
Reference Geography Data
Attributes 3 through 66 each store a “Reference Node Attributes” data structure that describes a single
node in the Reference Geography. Attribute 4 describes the expected first node to the right of the master(MAC ID 0), attribute 5 describes the node to the right of that, etc. The Reference Node Attributes data
structure contains all of the information needed to describe a Reference Geography for a network. The
data structure described in Figure 14 is used for each of these attributes.

2017 ODVA Industry Conference

11©2017 ODVA, Inc.

Figure 14: Reference Node Attributes Data Structure Definition
MemberID
1

Name

Vendor ID

Data TypeUINT

Description of Attribute

Vendor ID of the Node

Semantics of Values

Identity Object Instance 1
Attribute 1 of the node.
Default Value = 0

2

Device TypeUINT

Device Type of the NodeIdentity Object Instance 1
Attribute 2 of the nodeDefault Value = 0

3

Product Code

UINT

Product Code of the NodeIdentity Object Instance 1
Attribute 3 of the nodeDefault Value = 0

45Revision

Serial Number

STRUCT of:

Identity Object Instance 1
Attribute 4 of the node

USINT

Major Revision

USINT

Minor Revision

UDINT

Serial Number of the Node1

Default Value = 0.0

Identity Object Instance 1
Attribute 6 of the nodeDefault Value = 0

6

MAC IDUINT

MAC ID of the Node0– 63 are valid MAC IDs
Default Value = 0xFF (notconfigured)

7

Geography Match
Keying Mask

WORD

Specifies the device keying criteria
used to compare a Reference Nodeand an Actual Node to determine ifthey match

See Member 7 description
below.
Default = 0x17

1.

The reference node Serial Number may be set to the value consumed during a Network Geography Request operation.
If a reference geography is delivered using the Set_Attribute services and an actual serial number is not know, then this
attribute should be set to the Default Value of 0.

Individual Reference Numbered Position instance attribute values may be set with the
Set_Attribute_Single, Set_Member or Set_Attribute_List services. This is typically done when aCommissioning Tool delivers a Reference Geography to a node with the DoT Commissioning Object at
MAC ID 0.
The various Reference Numbered Position instance attribute values may also be set by aGeography_Sync_Request service which copies Actual Numbered Node attribute data to corresponding
Reference Numbered Node attributes.

2017 ODVA Industry Conference

12©2017 ODVA, Inc.

Member 7 “Geography Match Keying Mask” specifies the device identity criteria used to compare
Reference Geography data with Actual Geography data for a node during geography compare
operations. Each bit in the mask enables a comparison to be used: Bit 0 – Vendor ID Match: Identity Object Instance attribute 1
 Bit 1 – Device Type Match: Identity Object Instance attribute 2
 Bit 2 – Product Code Match: Identity Object Instance attribute 3
 Bit 3 – Major Revision Exact Match: Identity Object Instance attribute 4 (high byte)
 Bit 4 – Major Revision Match or Higher: Identity Object Instance attribute 4 (high byte) is <=Major Revision of the Actual Node Data
 Bit 5 – Minor Revision Exact Match: Identity Object Instance attribute 4 (low byte)
 Bit 6 – Minor Revision Match or Higher: Identity Object Instance attribute 4 (low byte) is <=Minor Revision of the Actual Node Data
 Bit 7 – Serial Number Exact Match: Identity Object Instance attribute 6
 Bits 8-15 – Reserved and shall be 0.
A bit value of 1 signifies that the match criteria for that bit should be used when comparing Reference
Node Attribute data to Actual Node Attribute data for a numbered position. For example, the value 0x0F
corresponds to the following bits being set: Bit 0 – Vendor ID Match = 1
 Bit 1 – Device Type Match = 1
 Bit 2 – Product Code Match = 1
 Bit 3 – Major Revision Exact Match = 1
 Bit 4 – Major Revision Match or Higher = 0
 Bit 5 – Minor Revision Exact Match = 0
 Bit 6 – Minor Revision Match or Higher = 0
 Bit 7 – Serial Number Exact Match = 0
When comparing Reference Node Attribute data to Actual Node Attribute data for a numbered position, avalue of 0x0F means that Vendor ID, Device Type, Product Code and Major Revision of a Reference
Node number must match the corresponding values in the corresponding Actual Node number.
Bit 3 and Bit 4 cannot be set at the same time. Bit 5 and Bit 6 cannot be set at the same time. If a Set
service attempts to set both bits at the same time, the general status response 0x09 – “Invalid attributevalue” is returned.
This member defaults to the value of 0x17.

Actual Geography Data
Attributes 183 through 246 each return an “Actual Node Attributes” data structure that describes a single
node in the Actual Network Geography. Attribute 184 describes the first position to the right of the master(MAC ID 0), attribute 185 describes the node to the right of that, etc. The Actual Node Attributes data
structure contains all of the information needed to describe an Actual Geography for a network. The data
structure described in Figure 15 is used for each of these attributes.

2017 ODVA Industry Conference

13©2017 ODVA, Inc.

Figure 15: Actual Node Attributes Data Structure Definition
MemberID
1

Name

Vendor ID

Data TypeUINT

Description of Attribute

Vendor ID of the Node

Semantics of Values

Identity Object Instance 1
Attribute 1 of the nodeDefault Value = 0

2

Device TypeUINT

Device Type of the NodeIdentity Object Instance 1
Attribute 2 of the nodeDefault Value = 0

3

Product Code

UINT

Product Code of the NodeIdentity Object Instance 1
Attribute 3 of the nodeDefault Value = 0

45Revision

Serial Number

STRUCT of:

Identity Object Instance 1
Attribute 4 of the node

USINT

Major Revision

USINT

Minor Revision

UDINT

Serial Number of the Node

Default Value = 0.0

Identity Object Instance 1
Attribute 6 of the nodeDefault Value = 0

6

MAC IDUINT

MAC ID of the Node0– 63 are valid MAC IDs
Default Value = 0xFF (notpresent)

7

Duplicate MAC ID
Fault Status

UINT

Duplicate MAC ID Fault Statusof the Node

Network Access State
Machine Communication
Faulted State for theDevice.
0 = Not Faulted (default)
1 = Faulted.

2017 ODVA Industry Conference

14©2017 ODVA, Inc.

Automatically Applying a Reference Geography – Automatic Network Commissioning
Consider the use case where the system designer or panel builder wants to specify a network Nodal
Geography, including the relative positions of each networked device in a panel and specify nodeaddresses for each device, all before the actual network is built. Ideally, the system designer would be
able to work “off-line” with a commissioning tool to design his network, and at a later time, “download” the
network geography to a network master or CIP router, and have the network master or CIP routerautomatically check if the Actual Nodal Geography “matches” (is compatible with) the Reference
Geography that was downloaded. Then if the Reference and Actual Geographies matched, automaticallycommission the entire network based on the information in the Reference Geography.
This use case will be supported in devices that implement the DoT Commissioning Object. Attribute 99“Auto Apply Reference Geography” will enable the automatic invocation of the“Apply_Reference_Geography” service to the Actual network. This “Auto Apply” can effect behavior
during an initial power up, after a new Reference Geography has been written to the Reference data
attributes (attributes 2-66) or during a device replacement operation.
The “Auto Apply Reference Geography” operation works as follows:
After power up initialization has been completed, or after a new Reference Geography has been
established, the following occurs if this attribute 99 “Auto Apply Reference Geography” is set to
1=Enabled:
1. A Network_Geography_Request service is executed to determine the Actual Geography of the
network. This service uses the Select line to trigger all devices on the wire to produce Group 5
device-identifying messages. The messages are consumed in the order that they are produced,
which reflects the relative position of each device on the wire. The information is stored in DoTCommissioning Object attributes 2-66 to form the “Actual Geography” of the network.
2. The Actual Geography is compared to the Reference Geography specified in attributes 182-246
using the various Geography Match Keying Masks contained in the Reference Geography.
3. If the Actual and Reference Geographies match, the MAC IDs of all Actual Position nodes arecommissioned to match the MAC IDs specified in their corresponding Reference Numbered
Position attributes. For faulted nodes, this is done using the Group 4 Faulted Node Recovery
protocol. For nodes that are not faulted, this is done by setting the MAC ID (attribute 1) of theDeviceNet Object.
4. After all nodes have been commissioned, the “Geography Mismatch” bit (bit 2) in the Attribute 1(Status) is cleared
Flexible Addressing – Not Auto-Addressing
Traditional auto-addressing schemes limit address assignment to sequential addressing exclusively. In
real applications it is quite common in the life cycle of a system to add a node to the network, but not want
to affect the node addresses of the existing nodes in the cabinet. Consider the following system:

4 5 6 71

8

2 3
RelaysStarters

2017 ODVA Industry Conference

9

Push Buttons

15©2017 ODVA, Inc.

Suppose a new safety relay is be added to the cabinet as shown below.
New Safety Relay
4 5 6 71

8

2 3
RelaysStarters

9

Push Buttons

In this example, use of traditional sequential auto addressing is not desirable since it would bump thenode addresses of all of the nodes to the right of the new safety relay (the starters and push buttons) andprobably break the existing logic in the controller as a result. In this case, a traditional DeviceNet nodeaddressing method (for example, writing to the MAC ID attribute of the DeviceNet Object), perhaps
coupled with nodal geography discovery and display is more appropriate.
Now consider the case where a machine designer needs to incorporate varying numbers of each type ofdevice in a “base system” but would also like to be able to add optional devices to the base design
without affecting the basic machine design and controller logic. The example below shows such a systemwith all relays addressed left to right starting at MAC ID 1, all starters addressed left to right starting at
MAC ID 10, and all push buttons addressed left to right starting at MAC ID 20. This way the machine
designer could add an optional relay at MAC ID 5 without affecting the starter or push button device nodeaddresses in his base system.

10 11 12 13
1 2 3

20

4

RelaysStarters

21

22

Push Buttons

To accomplish this, the machine builder could connect all of the nodes in his system in their “out of thebox” state (MAC ID 63). On initial power up, all but one of the nodes will fail the Duplicate MAC ID Checkand enter the “Communication Faulted” state. The faulted nodes in the figure below are denoted by “CF”.

CF CF CF CF
CF

63 CF CF CF
RelaysStarters

2017 ODVA Industry Conference

CF

CF

Push Buttons

16©2017 ODVA, Inc.

A DeviceNet of Things commissioning tool would initiate a network geography discovery operation anddisplay the Actual Geography shown above. Since many of the nodes are in the “Communication Faulted”
state, the commissioning tool would need to use the “Group 4 Offline Connection Set” described inVolume 3 Section 2-11 to recover and set the MAC IDs of the faulted nodes. Setting MAC IDs in Group 4
is done by connecting to nodes by specifying Vendor ID and Serial Number. This information is containedin the Group 5 “Offline Status” messages that are produced by each node during the node geography
discovery sequence. These messages contain the Vendor ID, Communication Faulted Status and Serial
Number for the network nodes.
When the network geography discovery operation has run to completion, the commissioning tool has allof the information it needs to individually connect to and address each “Communication Faulted” node on
the network individually using the Group 4 Offline Ownership protocol, and the Group 4 Communication
Faulted protocol.
Automatic Device Replacement and Geographic Device Keying
It is common for system maintenance personnel to replace system components in a panel. Many
DeviceNet systems today implement an “Auto Device Replacement” feature where the replacement of aremoved device with a like device with compatible identity keys can be accomplished automatically. In
these systems, the new replacement device is connected to the network at its default node address of 63.
When the network master sees the replacement device at node 63 come on-line, it sets the replacement
device’s MAC ID to that of the original device and downloads stored configuration data to the device sothat no intervention is needed from the maintenance personnel to commission or configure the newdevice.
The replacement of a node with a compatible device on a DeviceNet of Things network will include theability to check that the replacement device was placed on the network at the same geographic position
as the original device before the ”Auto Device Replacement” feature is triggered, effectively adding a new
and important device keying criteria.
Consider the following system where the contacts in the relay at node address 2 weld closed, and therelay must be replaced.
Relay at MAC ID 2
Is to be replaced
4 5 6 71

8

2 3
RelaysStarters

9

Push Button

If “Auto Apply Reference Geography” is enabled in the DoT Commissioning Object in the network masterdevice, the following sequence would be initiated”
1. When the disappearance of a node specified in the Reference Geography is detected,
AND
2. A new node comes on-line, i.e. a Duplicate MAC ID Request message is detected on the
network, a Network_Geography_Request service is executed to establish the new Actual
Geography of the network.
3. If the newly detected node is found to be at the same geographic position as the node thatdropped off the network, the Geography Match Keying Mask is used to determine if the newly
detected node is compatible with the Reference Position node. If it is, the MAC ID of the newnode is set to the Reference Position MAC ID. If the new node is found to be incompatible, noaction is taken.
2017 ODVA Industry Conference

17©2017 ODVA, Inc.

4. Optionally, the master device could automatically download a complete saved device
configuration to the new device. All of this could be done without any user intervention.
But if the user removes node 2 and places a compatible relay to the right of the push button at MAC ID 9,a Nodal Geography Discovery operation would point out that a compatible node that was installed on the
network is geographically located at a different position on the wire than the original device at MAC ID 2.
If the Auto Device Replace operation requires a geographic location match and a compatible device
keying match, it would do nothing. If, however, the compatible relay had been placed on the network
between MAC ID 1 and MAC ID 3, then an Auto Device Replace operation would be performed.
Compatible device
in “out of the box”
state placed here
4 5 6 71

8

3
RelaysStarters

963

Push Button

An extension of the device replacement use case would be to consider a system where multiple nodes atvarious network locations are to be replaced at the same time. Consider the following system where therelay at MAC ID 2 and the push button at MAC ID 9 need to be replaced.
These 2 devices are to be replaced
4 5 6 71

8

2 3
RelaysStarters

9

10

Push Button

The user could first replace the 2 devices on the network with 2 compatible devices and locate them inthe same geographic position that they were originally in.
These 2 compatible devices are placed on the
network in their “out of the box” configurations
4 5 6 78

1 63 3
RelaysStarters

CF

10

Push Button

A “Discovery of Nodal Geography” operation would reveal that a compatible relay had been placed on the
network between nodes 1 and 3 at MAC ID 63, and that a node has been placed between nodes 8 and10, but in this example the node would enter the Communication Faulted state since the new relay would
defend MAC ID 63 when the new push button broadcasts its Duplicate MAC ID Request message on
power up.

2017 ODVA Industry Conference

18©2017 ODVA, Inc.

The master device could first perform an “Auto Device Replace” operation on the relay located between
MAC IDs 1 and 3 resulting in the following network nodal geography:
4 5 6 71

8

2 3
RelaysStarters

CF

10

Push Button

Then the master could use the Group 4 faulted node recovery protocol to set the faulted pushbutton’snode address to 9. Finally, the master device could complete the “Auto Device Replace” operation on thepush button located between MAC IDs 8 and 10 resulting in the following network nodal geography:

4 5 6 71

8

2 3
RelaysStarters

9

10

Push Button

Now consider the following system where the relays at MAC IDs 2 and 3, which have the same device
keying, are to be replaced.
These 2 devices are to be replaced
4 5 6 71

8

2 3
RelaysStarters

9

10

Push Button

The user places a single new relay devices on the network with compatible device keying and locates it to
the right of node 1.
This compatible device is placed on the
network in its “out of the box” configuration
4 5 6 7
8

1 63
RelaysStarters

CF

10

Push Button

A discovery of nodal geography operation would reveal that a compatible relay had been placed on the
network between nodes 1 and 4 at MAC ID 63. But there is no way to determine if this new node should
replace the old node 2 or 3, thus no Auto Device Replace operation would be initiated.

2017 ODVA Industry Conference

19©2017 ODVA, Inc.

But if the user replaces the 2 devices on the network with 2 compatible devices and locates them in thesame geographic position that they were originally in, there is nothing that would prevent the system fromautomatically replacing both devices.
These 2 compatible devices are placed on the
network in their “out of the box” configurations
4 5 6 78

1 63 CF
RelaysStarters

CF

10

Push Button

Finally, consider the following system where the relays at MAC IDs 2 and 3, which have the same device
keying, are to be replaced.
These 2 devices are to be replaced
4 5 6 71

8

2 3
RelaysStarters

9

10

Push Button

The user replaces the 2 devices on the network with 3 compatible devices and locate themgeographically between nodes 1 and 4.
These 3 compatible devices are placed on the
network in their “out of the box” configurations
4 5 6 78

1 63 CF CF
RelaysStarters

CF

10

Push Button

A discovery of nodal geography operation would reveal that 3 compatible relays had been placed on the
network between nodes 1 and 4. But there is no way to determine which of these 3 nodes should replace
the old node 2 or 3, thus no Auto Device Replace operation would be initiated.

DeviceNet of Things Object Model
The following figure illustrates the abstract object model of a DeviceNet of Things product. Allcomponents of the DeviceNet object model are present, and a DeviceNet of Things Link Object is added
to the model to indicate that the Select line sequential service delivery feature for DeviceNet of Things
devices is supported. The inclusion of an instance of the DeviceNet of Things Link Object in a device iswhat classifies it as a DeviceNet of Things device and not a traditional DeviceNet device.

2017 ODVA Industry Conference

20©2017 ODVA, Inc.

Figure 16: DeviceNet of Things Device Object Model

Unconnected
Message
Manager

Unconnect
ed Explicit
Messages

Explicit Message
Connection Objects

DeviceNet
ObjectLink
Consumer
ObjectConnection
Based
Explicit
Messages

Link
ProducerObjectDeviceNetof Things
Link
ObjectI/O Connection
Objects
Link
Consumer
ObjectMessage
RouterI/O
Messages
Link
ProducerObjectApplicatio
Applicatio
Applicationn Objectsn Objects
Objects

2017 ODVA Industry Conference

21©2017 ODVA, Inc.

DeviceNet of Things Power Architecture
Three key requirements drive the DeviceNet of Things power architecture design:
1. Commercially available “off-the-shelf” power supplies must be allowed.
2. Both Network and Switched power must be delivered.
3. It must be possible to size a single power supply for a system and use “Power Taps” to distribute
power for the network.
The DeviceNet of Things media will be rated for 4Amps. In many systems, the number of devices on the
network would cause the 4 Amp limit on Network and/or Switched power to be exceeded. For example,
the high inrush current needed to actuate many commercially available contactor coils might limit the
number of motor starters that can be placed on the wire before the 4 Amp limit is reached. To address
this problem, a Power Tap architecture with four types of power taps has been defined. The Power Taps
will serve to segment the power delivered to the network media. Figure 17 illustrates the four possible
types of Power Taps that would be needed for DoT networks:
1. A First Tap (the leftmost Tap in Figure 17)
2. A Switched Power Tap (SP Tap in Figure 17)
3. A Network Power Tap (NP Tap in Figure 17)
4. A Network and Switched Power Tap (NP & SP Tap in Figure 17)

Figure 17: DeviceNet of Things Power Tap Types
Upstream

Downstream

First TapNP TapSP TapSwitched Power 1

NP & SP Tap

Switched Power 3

Switched Power 2
Network Power 2

Network Power 1

Terminator

Network Power 3

24 VDC Power Supply

The First Tap will generally be the first device downstream from Node 0 (the Master or CIP Router). It willneed to inject Network Power both upstream (to power the Master or CIP Router) and downstream(Network Power segment 1 in Figure 17). The First tap will also need to inject Switched Powerdownstream (Switched Power segment 1 in Figure 17). Generally, the Master or CIP Router will not need
Switched Power delivery.
A Switched Power Tap (SP Tap) will allow Network Power to be continuous through the tap, but will breakthe Switched Power + conductor allowing fresh 24 VDC power to be injected, forming a new SwitchedPower segment (Switched Power segment 2 in Figure 17).
A Network Power Tap (NP Tap) will allow Switched Power to be continuous through the tap, but will breakthe Network Power + conductor allowing fresh 24 VDC power to be injected, forming a new Network
Power segment (Network Power segment 2 in Figure 17).
2017 ODVA Industry Conference

22©2017 ODVA, Inc.

A Network and Switched Power Tap (NP & SP Tap) will break both the Network Power + conductor andthe Switched Power + conductor allowing fresh 24 VDC power to be injected, forming a new Network
Power segment (Network Power segment 3 in Figure 17) and a new Switched Power segment (SwitchedPower segment 3 in Figure 17).
Adjustable Smart Power Taps
Rather than offer separate catalog numbers for the 4 Power Tap types, an Adjustable Smart Power Tap
design can be considered. Figure 18 shows a block diagram for such a tap.
Figure 18: Adjustable Smart Power Tap Types

NP+ INNP- IN
SP+ IN

Logic Controlled Tap
Type Switches

LEDs
CAN+

R1
Processor

R3

SP- INCAN-

NP+ OUTNP- OUTSP+ OUT

DNoTInterface

SP- OUT
Fuse

SupplyVoltage

Tap Type Selector
SwitchFilter/Limiter/
Boost

Logic Controlled Tap
Type Switches

I Sense

SwitchNP+

R2

V senseV SenseNP-

Filter/Limiter/
Boost

Logic Controlled Tap
Type Switches

I Sense

Switch

SP+

R4

Fuse

V SenseSP-

Mandatory

Optional

The tap would include 4 sets of switches (R1 – R4 in Figure 18) to either inject new power from the
Supply Voltage to create a new power segment, or bypass the Supply Voltage to allow continuous power
through the tap. The R1 – R4 switch settings are controlled by a “Tap Type Selector Switch” to determine
the tap type. Figure 19 summarizes how the switches would operate.

2017 ODVA Industry Conference

23©2017 ODVA, Inc.

Figure 19: Adjustable Smart Tap Configuration
SwitchFirst Tap

SP TapNP TapSP & NP Tap

Description

R1 (NP Bypass)

On

On

-

-

Connects NP IN to NP OUT

R2 (NP Inject)

On

-

On

On

Connects Voltage Supply to NP OUT

R3 (SP Bypass)

-

-

On

R4 (SP Inject)

On

On

-

Connects SP IN to SP OUT
On

Connects Voltage Supply to NP OUT

Smart Taps, Smart Terminators and Network Infrastructure Diagnostics
Many common field problems encountered when deploying traditional DeviceNet are related to Network
Power supply sizing problems and improper network termination. The introduction of “smart” networked
components that have traditionally been passive (non-networked) in nature can provide useful network
diagnostic data to the user. Referring back to Figure 18, the smart power tap includes a microprocessor
and a DeviceNet of Things network interface. This allows the power tap to report diagnostic informationsuch as CIP energy data for each power segment. This information can be used to inform the user when
the current being drawn by the devices in a power segment is nearing or exceeds the current rating of the
network media. At a system level, smart tools can be developed that know the current and power draw of
the individual devices on a network and suggest to the user how to segment the Network and SwitchedPower for his system. Since smart power taps can participate in the discovery of the Actual Network
Geography, the user can be informed of potential problems with his power segmentation in an actual
system.
The improper termination of DeviceNet network media is a common problem in the field. Since the costof implementing a simple DeviceNet of Things node will be small (Cortex M0+ microprocessors with
ample on-board Flash, RAM, CAN and other peripherals are available for less than $1 and the cost of thephysical layer interface will be reduced for DoT), it makes sense to provide “Smart Terminators”. Figure
20 illustrates a block diagram for a DoT Smart Terminator. Since Smart Terminators can participate in
the discovery of the Actual Nodal Geography, the user can be informed when his network is not
terminated properly. Note that in the network depicted in Figure 17, only 1 terminator is shown. This isbecause the DeviceNet of Things will require devices that implement the DeviceNet of Things
Commissioning Object to include a 120 ohm terminating resister in the device. This can be done
because these devices must be placed as the first device on the network at MAC ID 0.

2017 ODVA Industry Conference

24©2017 ODVA, Inc.

Figure 20: Smart Terminator
Network Power +CAN +CAN Network Power SelectSwitched Power Switched Power +

120
ohms
CAN
Transceiver

Microprocessor
VIsense

VIsensePower Supply

Smart Drops – Extending DeviceNet of Things Functionality to Existing DeviceNet Devices
DeviceNet is a mature network with a large number of devices available from a variety of vendors. In
order to protect the investment that vendors have made and offer a simple path to extending thefunctionality of the existing product portfolio, a “Smart Drop” device could be developed. The Smart Drop
would allow traditional devices to participate in DeviceNet of Things Select line and Group 5 messaging.
A Smart Drop would mainly act as simple DeviceNet to DeviceNet router. The DeviceNet of Things sideof the router would occupy a node address on the DeviceNet of Things network and would be able toparticipate in Select line services and produce Group 5 messages. Messages to be routed to and fromthe traditional DeviceNet device would be passed through the Smart Drop and be readdressed with theappropriate MAC ID as needed. If no traditional DeviceNet device is connected to the Smart Drop it would
participate on the network as a node of type "Network Adaptor” and report its own Identity Object keys.
Figure 21 below depicts such a device.

2017 ODVA Industry Conference

25©2017 ODVA, Inc.

Figure 21: Smart Drop

SP/NP

P/S

SP

RelaysStarters

Push Buttons

Smart Drop

Traditional
DeviceNet
DeviceTraditional
DeviceNet MediaDOT Push
ButtonSmart DropuProcessor

uProcessor

SelectNetwork +Network –
CAN +
CAN –
Control +Control –This approach would not affect the DeviceNet of Things media length budget since the drop to the
traditional device is a separate point to point DeviceNet network.

The DoT SIG and Specification Enhancement Status
The ODVA DeviceNet or Things SIG mission statement states the following:
The Special Interest Group for DeviceNet of Things ("SIG") seeks to expand the adoption of
DeviceNet to low cost, simple industrial devices that today typically are hardwired in thecommand-control and communication architecture found in today’s automated plant. In
the long term, this will help to accelerate the adoption of EtherNet/IP by expanding theapplication of the Common Industrial Protocol to new devices that, for the foreseeable
future would not otherwise be able to be included in the EtherNet/IP architecture, because
the cost of Ethernet connectivity remains too high. The result will be the availability of acomplete and seamless CIP network architecture from the simplest low cost devices to thehigher level supervisory systems and that reduces the user’s total cost of owner for the
automation architecture.

2017 ODVA Industry Conference

26©2017 ODVA, Inc.

In support of this mission, the SIG has approved the following specification enhancements and forwarded
them to the System Architecture SIG for review: DSE 0001-115 DeviceNet of Things Overview including:o An overview of work items for the SIG
o Additions to Volume 3 Chapter 1 DeviceNet Adaptation of CIP.
Feedback from the System SIG is pending.
 DSE 0001-114 DeviceNet of Things Objects including:o Volume 3 Chapter 2 protocol updates related to Group 5 and Select Line messagingo Volume 3 Chapter 5 updates to the DeviceNet Objecto Volume 3 Chapter 5 additions to define the DeviceNet of Things Link Object and theDeviceNet of Things Commissioning Object.
o Volume 3 Chapter 7 EDS file definition updates
Feedback from the System SIG has been received, updates are complete, forwarded back to
the System SIG for further review.
 CIPSE 0001-252 DeviceNet of Things Hooks including:o Volume 1 Chapter 5 and Chapter 7 tweaks in support of the DeviceNet of Things.
Feedback from the System SIG has been received, updates are complete, forwarded back to
the System SIG for further review.
 CIPSE 0001-256 Pushbutton Portfolio Profileo Adds a new device profile to support Pushbuttons, Selector Switches and Pilot Light
indicators to Volume 1 Chapter 6
Feedback from the System SIG is pending.
Also in support of our mission, the DoT SIG has engaged the DeviceNet Physical Layer SIG to define theneeded specification enhancements to support the new media, connector and power supply
requirements. The following specification enhancement is being prepared: DSE 0798-001 DeviceNet of Things Physical Layer
Further related specification enhancement work to support new low-end devices for the DeviceNet ofThings is being done in the ODVA Motor Control and Circuit Breaker SIG, most notably: CIPSE 0001-257 Circuit Breaker Profileo Adds a new device profile to support Circuit Breakers to Volume 1, Chapter 6
 CIPSE 0001-258 Circuit Breaker Objects
o Adds a new Circuit Breaker Supervisor Object definition to Volume 1, Chapter 5
 Various other CIPSEs to better support component based motor starters and other devices in the
ODVA Hierarchy of Motor Control Devices.
The DeviceNet of Things SIG will continue its work as follows: Define a Power Tap device profile.
 Define a Smart Terminator profile.
 Look into the development of other new device profiles as needed.
 Produce a DeviceNet of Things Conformance Test Specification.

2017 ODVA Industry Conference

27©2017 ODVA, Inc.

References
1. ODVA, THE CIP NETWORKS LIBRARY, Volume 1, Common Industrial Protocol (CIP™), Edition
3.20, April 2016
2. ODVA, THE CIP NETWORKS LIBRARY, Volume 3, DeviceNet Adaptation of CIP, Edition 1.14,
November 2013
3. Rockwell Automation, Auto device replacement (ADR) –1769-SDN Compact I/O DeviceNet
Scanner Module User Manual – Publication 1769-UM009E-EN-P, August 2009
4. John Harmon, 6 DeviceNet Sins Not to Repeat with EtherNet/IP, Sensortech, May 19, 2010******************************************************************************************************************************************************The ideas, opinions, and recommendations expressed herein are intended to describe concepts of the author(s) for the possible useof ODVA technologies and do not reflect the ideas, opinions, and recommendation of ODVA per se. Because ODVA technologies
may be applied in many diverse situations and in conjunction with products and systems from multiple vendors, the reader andthose responsible for specifying ODVA networks must determine for themselves the suitability and the suitability of ideas, opinions,and recommendations expressed herein for intended use. Copyright ©2017 ODVA, Inc. All rights reserved. For permission to
reproduce excerpts of this material, with appropriate attribution to the author(s), please contact ODVA on: TEL +1 734-975-8840
FAX +1 734-922-0027 EMAIL odva@odva.org WEB www.odva.org. CIP, Common Industrial Protocol, CIP Energy, CIP Motion, CIP
Safety, CIP Sync, CIP Security, CompoNet, ControlNet, DeviceNet, and EtherNet/IP are trademarks of ODVA, Inc. All othertrademarks are property of their respective owners.

2017 ODVA Industry Conference

28©2017 ODVA, Inc.