DEPARTMENT OF MECHATRONICS ENGINEERING, MANIPAL INSTITUTE OF TECHNOLOGY

MANIPAL

The CANopen Protocol

Structure, Scope, Applications and Future
Prospects
Vedant Prusty
8/15/2015

CANopen serves as one of the few truly independent communication protocols open to
customization and interfacing of various technologies on multiple networks. This report
introduces the basic structure of CANopen and its advantages. It also discusses examples of its
myriad applications and its future prospects in a fast developing world.

THE CANOPEN PROTOCOL - STRUCTURE, SCOPE,

APPLICATIONS AND FUTURE PROSPECTS

Submitted By:

VEDANT PRUSTY
Reg No 120929210
B.Tech | 7TH Semester | Section A
DEPARMENT OF MECHATRONICS ENGINEERING
MANIPAL INSTITUTE OF TECHNOLOGY, MANIPAL
vedant.prusty@learner.manipal.edu

The CANopen Protocol - Structure, Scope, Applications and Future Prospects

CONTENTS

1. Introduction.. 2
2. Structure of the CANopen Protocol.. 3
2.1.

The CAN bus. 3

2.2.

The CANopen Protocol 4

2.3.

The Object Dictionary... 6

2.4.

SDOs and PDOs... 7

2.5.

Communication Types..... 9

3. Applications of CANopen... 9
3.1.

The BioBike 10

3.2.

Sub-fractional horse-power Electric Motors with Integrated

CANopen interface 11

3.3.

Pipeline Welding based on CANopen 12

4. Advantages, Challenges and Future Prospects. 14

4.1.

Advantages and Disadvantages of CANopen..... 14

4.2.

The Future of CANopen... 15

4.3.

Summary and Outlook. 16

5. References... 17

Dept. of Mechatronics Engineering

The CANopen Protocol - Structure, Scope, Applications and Future Prospects

1. INTRODUCTION

CANOpen is a communication protocol and device specification used in

automation system. It is a commercial protocol typically related with
embedded networking. Since embedded systems are widely used in
automations, CANOpen does not only exist in our daily life, but also in
variety of industries, such as household applications, automobiles, medical
equipment, sub-sea facilities and so on. Some of these applications are so
sophisticated that it does not allow any fatal defect, like medical
equipment, and some other applications are too resource-consuming to
tolerate configuration delay, such as subsea platform.

The growing trend of integrating multiple independently manufactured

electronics components into a single compact system has given rise to the
idea of standardization of communication protocols. Such standards
enable the addition of newer components or nodes to the system over
time, allowing continuity in any ongoing project or research. In such a
scenario, CANopen offers a robust, holistic and time tested solution.
Although it is not a short period since CANOpen protocol is proposed,
there might still be some uncovered issues.

This report discusses the basic structure and features offeren by the
CANopen protocol. It then goes on to cite applications where CANopen

Dept. of Mechatronics Engineering

The CANopen Protocol - Structure, Scope, Applications and Future Prospects

has been successful, and then point out the challenges being faced in
keeping CANopen relevant in the future.

2. STRUCTURE OF THE CANOPEN PROTOCOL

2.1 The CAN Bus

The CAN (Controller Area Network) bus is a serial bus that works with a
differential tension. Each CAN node is connected in parallel. (Two
termination resistors of 120 Ohm at the ends of the bus are
recommended.) Here, a node represents any device following the same
communication protocol as the other devices in the network. The CAN-bus
specification has been there now for more than 20 years (being widely
used in the automation industry) and is well integrated in microcontrollers
today. Fig. 1 illustrates a typical CAN bus network with nodes.

Figure 1: A typical CAN bus network with nodes

Dept. of Mechatronics Engineering

The CANopen Protocol - Structure, Scope, Applications and Future Prospects

While the CAN bus was originally designed keeping communication of electronic
components in automobiles in mind, its application has evolved since then into
several fields. Development of the CAN bus started in 1983 at Robert Bosch
GmbH. The protocol was officially released in 1986 at the Society of Automotive
Engineers (SAE) congress in Detroit, Michigan. The first CAN controller chips,
produced by Intel and Philips, came on the market in 1987. The 1988 BMW 8
Series was the first production vehicle to feature a CAN-based multiplex wiring
system.

2.2 The CANopen Protocol

Real world problems require the integration of several devices that have same or
similar functionality. However, more than often, these devices may not be
interchangeable due to different implementation details, communication protocols
or parameter setups. The CIA CAN in Automation organization has created
several standards to define functionality of such devices so that they may be
used interchangeably. Devices profiles like generic I/O modules and drives and
motion control have been created. Today, there are many vendors selling
products with integrated CANopen protocol.
The

CANopen

standard

consists

of

an

addressing

scheme,

several

communication protocols and an application layer defined by a device profile. The

communication protocols have support for network management, device
monitoring and communication between nodes, including a simple transport layer
for message segmentation/de-segmentation. The basic CANopen device and

Dept. of Mechatronics Engineering

The CANopen Protocol - Structure, Scope, Applications and Future Prospects

communication profiles are given in the CiA 301 specification released by CAN in
Automation.
CAN may be implemented over a number of physical media as long as the
drivers are open-collector and each node can hear itself (and others) while
transmitting (this is necessary for its message priority and error handling
mechanisms).

Figure 2: The CANopen message frame

The message frames generally used to carry data are shown in Fig. 2. They
contain the following fields (this is a simplified description as the controller
takes care of the detail)
Start of frame (SOF)
Message Identifier (MID) the Lower the value the Higher the priority of the
message length is either 11 or 29 bits long depending on the standard
being used
Remote Transmission Request (RTR)
Control field (CONTROL) this specifies the number of bytes of data to
follow
Data Field (DATA) length 0 to 8 bytes
CRC field containing a fifteen bit cyclic redundancy check code
Acknowledge field (ACK) an empty slot which may be filled by any and
every node that receives the frame (it does NOT say that the node you

Dept. of Mechatronics Engineering

The CANopen Protocol - Structure, Scope, Applications and Future Prospects

intended the data for got it, just that at least one node on the whole
network got it.)
End of Frame (EOF)

CANopen allows the implementation of up to 127 CAN-nodes on a single bus.

Each node must be provided with a unique node ID. Each unique node allows the
use of more than one address number. In CANopen instead of addresses, they
are referred to as Communication Object Identifiers (COB ID).

2.3 The Object Dictionary

One of the central themes of CANopen is the object dictionary (OD), which is
essentially a table that stores configuration and process data. It is a requirement
for all CANopen devices to implement an object dictionary. The CANopen
standard defines a 16-bit bit index and an 8-bit sub-index. That is, it is
permissible to have up to 65536 indices and up to 256 subentries at each index.
The standard defines that certain addresses and address ranges must contain
specific parameters. As such, any CANopen master can read this index from a
network of CANopen slaves in order to uniquely identify each slave by name.
Some object dictionary indices, such as the device type (1000h) are mandatory,
and others, such as the manufacturer software version (100Ah) are optional. The
collection of mandatory indices represents the minimum object dictionary, which
is required to brand a device CANopen compliant.
The object dictionary is the method by which a CANopen device can be
communicated with. For example, one could write a true to the index in the
manufacturer-specific section of the object dictionary (2000h-5FFFh), which the
Dept. of Mechatronics Engineering

The CANopen Protocol - Structure, Scope, Applications and Future Prospects

device could interpret as an enable signal for acquiring data from a voltage input.
Conversely, the master may also want to read information from the object
dictionary to get the acquired data, or to find out how to device is currently
configured. The two communication mechanisms for accessing the object
dictionary are Service Data Objects (SDOs) and Process Data Objects (PDOs),
which will be explained later in this document.

2.4 SDOs and PDOs

Service Data Object (SDO)

The CANopen protocol specifies that each node on the network must implement
a server that handles read/write requests to its object dictionary. This allows for a
CANopen master to act as a client to that server. The mechanism for direct
access

(read/write)

to the servers object

dictionary

is

the

Service Data Object

(SDO).

The

whose

node
object

dictionary

is

accessed is referred
to

as

the

SDO

server, and the node

Figure 3: SDO Mechanism

grabbing the data is referred to as the SDO client. The transfer is always started
by the SDO client. SDOs allow access to a single entry in the Object Dictionary,

Dept. of Mechatronics Engineering

The CANopen Protocol - Structure, Scope, Applications and Future Prospects

specified by index and sub-index. They use the clientserver communication

model, where the client accesses the data and the server owns the target Object
Dictionary. (All relevant data that characterizes a device profile of a CANopen
device is implemented in an Electronic Data Sheet (EDS) file. The EDS organizes
objects in a dictionary that stores the relevant data.) SDOs are typically used for
device configuration or for accessing a large amount of data at a very low rate.
The difference between a Transmit and Receive SDO is that in case of a
Receive SDO a request to obtain the contents of an object must be sent first.

Figure 4: The CANopen device model

Process Data Object (PDO)

PDOs are used by connected nodes, for example in a twin motor configuration, to
exchange real time data during operation. PDOs allow up to 8 bytes of data to be
transmitted in one CAN message. This reduces the time to send the PDO data
over the CAN-bus. Process data represents data that can be changing in time,

Dept. of Mechatronics Engineering

The CANopen Protocol - Structure, Scope, Applications and Future Prospects

such as the inputs (i.e. sensors) and outputs (i.e. motor drives) of the node
controller. Process data is also stored in the object dictionary.

2.5 Communication Types

CANopen defines a number of communication classes for the input and output
data (process data objects):

Event driven: Telegrams are sent as soon as their contents have changed.
This means that the process image as a whole is not continuously
transmitted, only its changes.

Cyclic synchronous: A SYNC telegram causes the modules to accept the

output data that was previously received, and to send new input data.

Requested: A CAN data request telegram causes the modules to send

their input data.

The desired communication type is set by the Transmission Type parameter.

3. APPLICATIONS OF CANOPEN

Over time, CANopen has found its way into myriad applications involving
embedded systems as well as large computer networks. This report will now
present a few cases where CANopen was used in various capacities.

Dept. of Mechatronics Engineering

The CANopen Protocol - Structure, Scope, Applications and Future Prospects

3.1

The BioBike

The BioBike being developed at Hochschule Ulm since 1994 is a device which
can be used to assess a drivers performance. It employs various modules
including assessing and controlling seat and handlebar position and height, the
angular velocity of the pedal, power brakes, etc. Additionally, the project holds
great prospects in the field of physical rehabilitation, given the systems ability to
analyze human performance and respond accordingly. This project BioBike has
the objective of developing a special test bench for bikers, covering
biomechanics, effective pedaling and optimal power consumption.
The Aim of this author was to implement the CANopen communication protocol
(replacing simple serial communication) to communicate with the various motors
in the device. The nodes in the system consisted of 4 motors for the up-down and
forwards-backwards motion of the seat and handlebars. Additional modules
included an Angular Velocity calculation module, and brake power calculation
module, etc. Each of these serve as slave nodes. A master interface was
designed to bridge communication between the PC and the BioBike.

A major challenge in this project

was

the

management

of

data

traffic. Each node kept sending

across

PDOs

interface,

to

thereby

communication

Figure 5: The BioBike being developed at Hochschule Ulm

Dept. of Mechatronics Engineering

overwhelming

the

master
clogging

lines

the

PC

and

with

10

The CANopen Protocol - Structure, Scope, Applications and Future Prospects

incoming data. However, the robust options provided in the CANopen

specification for simultaneous message broadcasting by multiple nodes, coupled
with minor customization proved that CANopen had been the right choice for the
BioBike. It also left the stage open for addition of new modules as nodes, in a
plug-and-play type scenario.

3.2

Sub-fractional horse-power Electric Motors with integrated CANopen

interface
The company Gefeg-Neckar Antriebssysteme is successor of the motor
manufacturers Gefeg, founded in 1948, and Neckar Kleinstmotoren, founded in
1967. The latter produced compact brushless dc motors with integrated electronic
motor control since 1995. In 2005, the merged company started the development
of a new electronic platform with the capability of bus communication.
Feedback from customers showed that CANopen was a good choice for a high
performance but cost-effective bus solutions.

The CAN interface provides for bus

communication using the CANopen
protocol
(Drive Profile CiA 402). Customers
not operating a bus system may
still control the motor via analog or

Figure 6: Brushless motor with integrated CANopen interface

(MC663)

digital set point signals.

Dept. of Mechatronics Engineering

11

The CANopen Protocol - Structure, Scope, Applications and Future Prospects

The integrated bus communication provides certain benefits here, too, since it
makes easy testing and parameter setting of the drives possible. The firmware
also includes a boot loader.
Therefore, firmware update can be easily done through the CANopen interface.
The integrated CAN interface also enables an easy, cost effective but detailed
test of these motors in the production line. For the final test, a new test system
has been developed.
It utilizes the CANopen protocol to communicate with the integrated electronic
platform (Drive Profile DSP 402). The test program is based on the routines of
the commissioning software.

3.3

Pipeline Welding Based on CANopen

Automatic welding has been used frequently on offshore pipeline projects. The
productivity and reliability are most essential features of the automatic welding
system. In older to satisfy the requirements of all-position welding process that
welding system can weld with mated welding parameters at any position, a
master-slave CAN-bus network control welding system is constructed, which is
composed of CAN-bus master and slave based on CANopen communication.
Welding generator, digital servo drives considered as slave are successfully
integrated in all-position pipeline welding system. By means of automation device
specification based on PC control to deploy equipmental Objects Dictionary, it
can ensures the real-time and fast transmission of process data objects by using
synchronous object transmission.

Dept. of Mechatronics Engineering

12

The CANopen Protocol - Structure, Scope, Applications and Future Prospects

Figure 7: Pipeline Welding System Control Network

The aim of this development is to develop a new generation automatic pipeline

welding system based on cutting-edge design and practical welding physics to
minimize downtime caused by weld defects and machine faults on the barges.
The real-time control network data exchange model based on soft PLC and realtime interconnection field-bus is established. Process monitoring and job data
transfer are possible using delicate software running on a Windows system via
CANopen network. In older to satisfy the requirements of all-position welding
process that welding system can weld with mated welding parameters at any
position, a master-slave CAN-bus network control welding system is constructed,
which is composed of CAN-bus master and CAN-bus slave based on CANopen
communication.

Dept. of Mechatronics Engineering

13

The CANopen Protocol - Structure, Scope, Applications and Future Prospects

4. ADVANTAGES, CHALLENGES AND FUTURE PROSPECTS

For many years, Controller Area Network (CAN) and CANopen, a higher-layer
protocol based on CAN, represented the best choice for low-cost industrial
embedded networking. However, since the official introduction of CAN in 1986,
there has been a quest to replace CAN and CANopen to overcome the most
obvious shortcomings such as limited baud rate and limited network length.

4.1

Advantages and Disadvantages of CANopen

CAN and CANopen, used as fieldbus systems for embedded solutions, combine
a number of advantages that cannot be matched by Ethernet TCP/IP. They are:
Extreme Reliability and Robustness
No Message Collision
Very Low Resource Requirements
Low-Cost Implementation
Designed for Real-Time Applications
Very Short Error Recovery Time
Support of Device Profiles (CANopen only)
However, there are some disadvantages of using CAN and CANopen, the
biggest being the limited network length (~120 feet at a 1 MBit/sec baud rate).
The disadvantages are:
Limited network length (depending on baud rate)
Limited baud rate of 1 MBit/sec
Limited bandwidth

Dept. of Mechatronics Engineering

14

The CANopen Protocol - Structure, Scope, Applications and Future Prospects

CANopen is basically a software add-on to provide network management function

to CAN. The side effect is a reduced CAN bandwidth. The degree of bandwidth
loss depends primarily on the use of Service Data Objects (SDO) and Process
Data Objects (PDO). Only a meticulous housekeeping can guarantee the best
possible performance.
In all fairness, the limited bandwidth is not a major problem, since CANopen
handles only the communication means between multiple processors (nodes);
the major control tasks take place within the nodes, and they do not necessarily
effect the bus communication.

4.2

The Future of CANopen

The future of CAN - as the physical layer - and CANopen - as a higher layer
protocol based on CAN - in the market must be seen separately.

Figure 8: CAN Nodes Sold in Millions (Source: CAN-in-Automation)

Dept. of Mechatronics Engineering

15

The CANopen Protocol - Structure, Scope, Applications and Future Prospects

The use of Controller Area Network is still dominated by its vast use in the
automobile industry, and there are no indications that CAN will be replaced in
short-term. Another stronghold is the use as a physical layer for the SAE J1939
protocol, and CAN will remain the most cost-sensitive fieldbus solution for small,
embedded systems.

CANopen is facing a much tougher battle, since its major application range is
now being attacked by the new Ethernet technologies. These CANopen legacy
applications are:
Motion Control
Industrial Machine Control
Other applications not necessarily effected by Ethernet technologies are:
Niche Applications (Lifts, Escalators, Gambling Machines, Telescopes,
Specialty Vehicle Systems, Cost-Sensitive I/O Control, etc.)
MilCAN
The Medical industry is still the biggest supporter of CANopen, but here, too, are
tendencies to look into Ethernet technologies due to the vastly increased data
throughput that these technologies offer.

4.3

Summary and Outlook

Minimizing the complexity of todays embedded systems is a general goal. If

multiple embedded networks are used, a common network protocol such as
CANopen, used across different communication technologies greatly simplifies
the overall implementation and maintenance effort.

Dept. of Mechatronics Engineering

16

The CANopen Protocol - Structure, Scope, Applications and Future Prospects

For existing systems abandoning currently used protocols might not always be
possible and sometimes customer demand might require the implementation of
specific network protocols. However, for new developments and implementations
a common network protocol must be seriously considered to keep development
times and system complexity in check. As such, CANopen will continue to serve
our networking and low traffic requirements. Even in the face of challenges such
as the Ethernet, CANopen remains a cost-effective, easy-to-implement solution.

5. References

1. Yu Luo, Xiangdong Jiao, Wengang Ji, Chanfeng Zhou, Lixin Zhang,

Tiexiang Li, Control Network Communication for Pipeline Welding Based
on CANopen, Advances in Control Engineering and Information Science,
Elsevier, 2011.
2. Wim Catteeuw, Piet Cordemans and Jeroen Boydens, Integration of a
CANopen Protocol Stack in an Embedded Application Employing the
CANFestival Stack, Annual Journal of Electronics, 2012.
3. CiA 301 - CANopen application layer and communication profile
4. Pfeiffer, O.; Ayre, A. & Keydel, C. Embedded Networking with CAN and
CANopen, Copperhill Technologies Corporation, 2008
5. Vedant Prusty, Implementing the CANopen Protocol and a new Interface
with Communication via Bluetooth in the BioBike, Hochschule Ulm,
Germany, July 2014.

Dept. of Mechatronics Engineering

17

The CANopen Protocol - Structure, Scope, Applications and Future Prospects

6. Olaf Pfeiffer, Christian Keydel, Andrew Ayre, Embedded Systems

Academy, CANopen on general serial networks, CAN in Automation, iCC
2005.
7. Wenlu Zhang, Formal Modeling and Analysis of The CANOpen Protocol
in Full Maude, Department of Informatics, University of Oslo, 2014.
8. Wilfried Voss, The Future of CAN / CANopen and the Industrial Ethernet
Challenge, ESD Eelectronics INC, USA.
9. Andrs Lelkes, Gefeg-Neckar Antriebssysteme GmbH, Compact drives
with CAN interface for industry applications, CAN in Automation, iCC
2012.

------------------------------------------------------------------------------------------------------------

---------------------------------------------------------------------------------------------------------Postscript: This report is part of a seminar on the same subject held at Manipal Institute
of Technology, between August and November 2015, submitted for partial fulfillment of
the 7th semester coursework of the Bachelor of Technology degree in Mechatronics.
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------Dept. of Mechatronics Engineering

18