CAN-based Communication System

CANopen - Higher-Layer CAN Protocol

CANopen is a "Layer 7" CAN protocol that defines communication and device functions for CAN-based systems. CANopen is a standardized, highly flexible, and highly configurable embedded network architecture used in industries such as Railway, Medical, Industrial, Agriculture, Heavy Truck & Bus, Marine, Off-Highway, Factory Automation, Aerospace.  CANopen is also becoming a popular choice for closed, company-specific embedded networks. 

The CANopen profile family specifies standardized communication mechanisms and device functionalities. The CANopen Standard is maintained by "CAN in Automation (CiA) International Users and Manufacturers Group" and can be implemented without a license.


  • Open architecture
  • Real-time transfer of process data without protocol overhead
  • Modular and scalable
  • Interoperability and interchangeability
  • Profile concept similar to Interbus-S and Profibus
  • Supported by many international manufacturers


CANopen Standard

The framework of this standard was developed as part of a project funded by the European Union. In 1995 the specifications that had been created up to that point were transferred to the organization CiA e.V. (CAN in Automation). Since then the standard has been maintained and further developed under the auspices of this CAN user organization. Since 2002 it has been available as a European standard (EN 50325-4 2002 Part 4: CANopen).

CANopen Device Structure

The CANopen standard describes the exchange of data in a CAN-based network. This standard defines both the fundamental communication mechanisms (communication profile) and the functionalities of communicating devices (device profile). This means that interpretation of process data that are transmitted over the bus are also defined under CANopen.

CANopen Device Model

Object Directory

Every CANopen device makes internal data (process data, parameters) available on the bus via a defined interface, whereby these internal data are organized in an object directory. Entries in the object directory are accessed via a 16-bit index and supplemental 8-bit sub-index. The index range is subdivided into logical segments to organize the structure so that it easier to comprehend by users. The name of a device, for example, can be read from index 0x1008 (sub-Index 0).

Index (hex)
not used
Data Types
Reserved for further use
Communication Profile Area
Manufacturer Specific Profile Area
Standardized Device Profile Area
Network variable area
System variable area
Reserved for further use


Show more

Communication Principles

There are two fundamental types of communication on a CANopen bus.


Service data objects (SDO) permit optional access to any desired entry of the object directory. Since these entries frequently exceed the maximum allowable size of a CAN message, i.e. 8 bytes, segmenting of data is performed by the SDO. The SDO server provides access to its object dictionary to an SDO client. The client can upload (read) or download (write) data from / to the server.


If information is sent cyclically to one or more devices, the use of Process Data Objects (PDO) is appropriate. In principle, a PDO is a CAN message that is fully configurable. Each CANopen device can have multiple transmit and receive PDOs. PDOs are configured with the corresponding entries in the object directory. These special entries allow changing the CAN ID as well as mapping bytes of the message to objects of the object dictionary.

Show more

Network Structure

Up to 127 logical devices may be addressed in a CANopen network. One of these devices must have CANopen Master functionality. This means that the Master can monitor other devices called Slaves and change their states. Each device is uniquely identified by its node address (1 to 127).

Show more


CANopen Documents

The CANopen specifications can be obtained from the home page of CiA. e.V.
The most important specification documents are:

  • DS 301 - This document is also known as the Communication profile and it describes the fundamental services and protocols used under CANopen.
  • DS 302 - Framework for programmable devices (CANopen Manager, SDO Manager)

Information on cables and connectors is contained in DR 303-3.

The behaviors of many device classes are already defined under CANopen in so-called device profiles (DS 4xx). These profiles describe:

  • Run-time behavior
  • Device-specific objects in the object directory
  • Error handling
  • Standard configuration of PDOs

CANopen Development Process

Find out how the tools can support you comprehensively throughout the development process here.
Show more
CANopen devices are selected based on the definition of overall functionality of a CANopen system. In the selection process, it does not matter whether the devices are purchased or developed in-house. For devices not yet developed, a suitable tool should be used to create an EDS/XDD file before device implementation. Advantages of this method are realized over the further course of the development process.
Show more
In this example, the total system consists of 3 CANopen devices whose functionality is described in the associated EDS/XDD file.
Show more
The EDS/XDD files are linked to a suitable configuration tool. The tool can then be used to set device parameters. This work step includes tasks such as configuring the PDOs (setting up mapping parameters, defining CAN identifiers), defining a CANopen Manager and parameterizing a heartbeat producer.
Show more
The configuration tool stores the device parameters in configuration files in a standardized format (DCF/XDC files). These are copies of the EDS/XDD files in which the configured device parameters are also saved
Show more
The sum of all configuration files represents a description of the total system. Based on this data, the developer can use a suitable tool to generate a simulation environment. Here we speak of a simulated total system.
Show more
For each DCF/XDC file, a reasonable simulation model is generated that reflects the behavior of the physical device. The behavior of a simulated node is produced from the DCF/XDC file; this file, together with the object directory, contains the device parameters configured using the configuration tool.
Show more
Initial tests may also be created based on the configuration data. Along with device-specific tests to check for CANopen conformity, application-specific tests may also be created. Device-specific tests can be fully generated based on the DCF/XDC files.
Show more

Tools for CANopen

Software tools from Vector offer a wide range of capabilities for simulation, development, analysis, testing and diagnostics of CANopen systems and components.

Development and Test of CANopen networks:
  • Create simulation environments (rest-of-bus simulation) for CANopen systems
  • Run environment for the simulation
  • Test generation
Analysis of CANopen networks:
  • Analyze and log the data traffic in CANopen networks
  • Stimulate message sequences
  • Play back recorded message sequences (Replay)
  • Configure CANopen devices
Project planning and configuration of CANopen networks:
  • Comprehensive graphic configuration of CANopen devices in the network
  • Project planning for entire CANopen networks
EDS Editor for CANopen:
  • Create and check EDS files (Electronic Data Sheet)

Hardware for CANopen

Software tools used to develop, simulate, test and maintain distributed systems require powerful and flexible hardware interfaces and logging solutions.

Vector offers you interfaces for CAN, LIN, J1708, Ethernet/IP and FlexRay as well as driver software and programming interfaces for use with Vector software tools and in customer-specific solutions.

Bus System
PC Connection
CAN, CAN FD, LIN and J1708:
Ethernet and CAN / CAN FD:
FlexRay and CAN / CAN FD:


* = not CAN FD capable

Additional Information