CANopen – Basics and Introduction to the CANopen Protocol

What is CANopen?

Short definition of CANopenKurzdefinition von CANopen

Typical use cases

CANopen is used wherever robust, real-time capable communication between multiple control units is required. Typical application areas include:

• Mechanical and plant engineering (e.g. packaging machines, handling systems)
• Mobile machinery and commercial vehicles
• Robotics and drive technology
• Medical technology, laboratory equipment, and diagnostic systems
• Railway, building, and energy technology

The combination of simple wiring, high noise immunity, and standardized device profiles makes CANopen particularly attractive for embedded systems. Developers benefit from the fact that many basic functions – such as the exchange of process data, parameter configuration, or error detection – are already defined by the protocol.

CAN and CANopen in comparison

CAN bus in brief

The CAN bus (Controller Area Network) is a serial fieldbus system that was originally developed for use in vehicles. It defines, among other things:

• the electrical signal (physical layer),
• bit transmission,
• the frame format (CAN frames),
• bus arbitration and error handling.

CAN itself therefore describes how bits are placed on the bus and how multiple nodes communicate in a collision-free and fault-tolerant manner. What the individual frames actually mean is left open. Without an additional protocol layer, each project and each application would have to define for itself which identifiers carry which data and how parameters are to be interpreted.

How does CANopen build on CAN?

The CANopen protocol is built directly on this foundation. CANopen uses CAN frames as the transport medium and defines:

• which frame types exist (e.g. for process data, configuration, errors),
• how devices are addressed,
• how parameters are structured and configured,
• how states and errors of a node are reported.

This raises the level of abstraction: instead of defining each device and each frame individually, standardized profiles and communication mechanisms are available. Developers no longer need to deal with every detail of the CAN frame, but work at the level of objects, parameters, and services provided by the CANopen stack.

CANopen in the OSI layer model

The OSI layer model helps to put things into context:

• The CAN bus mainly covers layer 1 (Physical Layer, ISO 11898-2) and layer 2 (Data Link Layer, ISO 11898-1).
• CANopen adds the higher layers on top, in particular layer 7 (Application Layer, EN 50325-4) and parts of the communication logic above that.

Put simply, CANopen takes on the role of the “language” that devices use to communicate over the CAN bus. It defines which data is transmitted with which meaning, how it is structured, and which services a CANopen node must support. For developers, this classification is important: hardware-related functions (transceiver, CAN controller) remain on the CAN level, while application logic and protocol behavior are implemented in the CANopen stack.

Architecture and core concepts of CANopen

The CANopen network model

A CANopen network consists of several nodes that are connected via the CAN bus. Each node has a unique node ID. Typically, one device in the network takes on the role of a CANopen manager (originally referred to as the master) – for example a central controller, PLC, or higher-level control unit.

Typical tasks of a CANopen manager include:

• Initializing the network and setting the nodes to the desired operating state,
• Configuring parameters via SDO communication,
• Starting and stopping cyclic data transmission,
• Monitoring nodes via heartbeat mechanisms.

The remaining nodes act as devices (originally referred to as slaves). They provide their process data (e.g. measured values, setpoints) and can be configured via standardized objects. CANopen clearly defines which protocol behavior a compliant device must exhibit – regardless of the manufacturer.

Object dictionary

Communication services: SDO, PDO, NMT, SYNC, EMCY, Heartbeat

The CANopen protocol provides various communication services that serve different purposes:

• SDO (Service Data Object):
  SDOs are used for configuration and targeted data exchange with the object dictionary. Using SDO, a master can, for example, write parameter values or read status information. SDO communication is flexible but comparatively slow and not intended for hard real-time.
• PDO (Process Data Object):
  PDOs are used for fast, cyclic exchange of process data. Typically, measurement values, status bits, or setpoints are transmitted in PDOs. A PDO can bundle several signals and is sent without additional protocol overhead – ideal for time-critical applications.
• NMT (Network Management):
  NMT commands control the state of a node (e.g. Start, Stop, Pre-Operational, Reset). With these commands, the NMT master can bring the entire network into operation or stop it in a controlled way.
• SYNC:
  The SYNC object is a special frame that serves as a synchronization pulse for the network. Nodes can link their PDO transmission to the reception of SYNC messages, enabling time-deterministic behavior.
• EMCY (Emergency):
  EMCY messages signal error conditions of a node. They are sent with high priority as soon as a defined error occurs and allow the higher-level controller to react quickly.
• Heartbeat:
  Via heartbeat mechanisms, nodes periodically indicate that they are still active and in the expected state. This allows the manager to detect failed or blocked nodes at an early stage.

Together, these communication services form the “toolbox” used to configure, monitor, and operate CANopen nodes in real-time operation.

State machine / device states

History and standardization

Origin of CAN in Automation

To improve this situation, the users’ and manufacturers’ organization CAN in Automation (CiA) was founded. The goal of CiA was to specify an open, cross-vendor protocol based on CAN. Out of this environment, CANopen evolved as a standardized application protocol with clearly defined device profiles.

Early on, the first specifications and implementations appeared in various industries, especially in mechanical engineering and mobile machinery. As CANopen became more widespread, the need for stable, standardized documents grew – forming the basis for later formal standardization.

Key CANopen standards

Over time, a number of documents related to CANopen have been created. The most important foundations are:

• CiA 301 – CANopen Application Layer and Communication Profile
  This document describes the fundamental structure of the CANopen protocol: communication objects, object dictionary, state machine, addressing, and the behavior of a CANopen-compliant device. CiA 301 is, so to speak, the “heart” of classic CANopen.
• CiA 1301 – CANopen FD
  With the introduction of CAN FD (Flexible Data-Rate), CANopen was extended as well: CANopen FD takes advantage of the extended capabilities of CAN FD, such as higher data rates and larger payloads. CiA 1301 defines how the CANopen concept is mapped onto CAN FD and which new options this enables.

In addition, there is a wide range of other CiA documents, for example for device and application profiles (such as CiA 401, CiA 402). For developers, this means that depending on the application, specific profile standards are relevant in addition to the basic documents.

Development and current relevance

Over the years, CANopen has evolved from a protocol for rather specialized applications into an established standard in industrial communication. Reasons for this include:

• the robust CAN bus technology in the background,
• clearly specified communication behavior,
• the wide range of available devices and protocol stacks.

Even though many other communication systems exist today (e.g. Industrial Ethernet variants), CANopen remains an attractive solution in numerous applications – especially where:

• robust, real-time capable communication on comparatively simple hardware is required,
• cost-sensitive, embedded systems are used,
• long product life cycles and high reliability are crucial.

With CANopen FD, the standard is also being adapted to modern requirements without abandoning the fundamental CANopen concept. For developers, this means that investments in CANopen know-how remain valuable in the long term, regardless of whether classic CAN or CAN FD is used.

Typical application areas and advantages

Industries and applications

• Mechanical and plant engineering
  Packaging machines, assembly systems, handling and conveyor technology frequently rely on CANopen. Sensors, drives, I/O modules, and operator panels are connected via a common network and managed by a central controller.
• Mobile machinery and commercial vehicles
  Agricultural machinery, municipal vehicles, construction machinery, or special-purpose vehicles use CANopen to network control units, engine controllers, joysticks, display units, and safety systems.
• Robotik und Antriebstechnik
  Servoantriebe, Schrittmotoren und Frequenzumrichter werden oft über das CANopen-Profil für Antriebe (CiA 402) eingebunden. So können Bewegungsabläufe standardisiert angesprochen und Antriebe verschiedener Hersteller in einem System kombiniert werden.
• Medizintechnik und Labortechnik
  In medizinischen Geräten, Laborautomaten oder Analysesystemen verbindet CANopen z. B. Pumpen, Sensoren, Aktoren und Bedienoberflächen. Die Anforderungen an Zuverlässigkeit und Diagnosefähigkeit sind hier besonders hoch.
• Railway, building, and energy technology
  In rail vehicles, elevators, door systems, heating and ventilation systems, or energy installations, CANopen enables robust communication even in harsh environments and over long product life cycles.

What all these applications have in common is that they involve distributed, embedded systems with multiple controllers, clear real-time requirements, and high demands on reliability – an ideal use case for CANopen.

Technical advantages of CANopen

From a developer’s perspective, CANopen offers a number of advantages:

• Standardized device profiles
  With profiles such as CiA 401 (I/O modules) and CiA 402 (drives), devices from different manufacturers behave largely the same. This simplifies the integration of new components and their replacement in the field.
• Clear structure through the object dictionary
  All relevant parameters of a device are accessible via the object dictionary. Instead of proprietary configuration protocols, there is a uniform scheme for reading and writing parameters.
• Flexible and efficient data exchange
  The combination of PDOs for fast process data and SDOs for configuration provides a good balance between real-time capability and flexibility. Developers can precisely define which signals are transmitted in which PDOs.
• Robust error handling and monitoring
  Mechanisms such as EMCY (error messages) and heartbeat ensure that errors can be detected and handled in a targeted manner. Failed nodes can be identified quickly.
• Interoperability and reusability
  Once implemented, CANopen functionality (e.g. a drive profile) can be reused in many projects. This reduces development effort and testing costs.
• Low hardware requirements
  CANopen builds on the proven CAN bus. Many microcontrollers already include integrated CAN controllers, and the physical interface is comparatively inexpensive.

Taken together, this makes CANopen an attractive option for many embedded projects where robust fieldbus communication is required.

CANopen solutions from MicroControl

CANopen protocol stacks

Based on the concepts described in this article, MicroControl offers modular CANopen / CANopen FD protocol stacks that are specifically optimized for use in embedded systems. The stacks are designed for low memory footprint and high performance and can be flexibly ported to different target hardware platforms via the standardized CANpie FD driver interface.

CANopen / CANopen FD master protocol stack
The CANopen master protocol stack forms the basis for complex controllers and the monitoring of complete CANopen networks. It supports, among others, the standards CiA 301 / CiA 1301 (FD), CiA 302, and CiA 305 and provides all essential services: SDO (client/server), PDO, NMT, EMCY, SYNC, as well as Layer Setting Services (LSS). The number of PDOs, SDO clients, and even the number of supported CAN channels can be configured at runtime to optimally adapt RAM and flash usage to the target application.

CANopen / CANopen FD slave protocol stack
The CANopen slave protocol stack is designed for intelligent sensors and actuators and is optimized for particularly low resource requirements. It implements the full functionality of the CANopen standards CiA 301 / CiA 1301 and CiA 305 and is therefore ideal for compact devices with limited memory and simple controllers.

CANopen bootloader protocol stack
For firmware updates via the CANopen network, MicroControl offers a CANopen bootloader protocol stack. It supports a reduced object dictionary scope as well as NMT, SDO (including block transfer), EMCY, heartbeat, and LSS, and enables the management of up to four flash memory areas for program and data. Updates are conveniently performed using the CANopen Download Tool, which is supplied as PC software.

Training, workshops, and engineering support

In addition to the protocol stacks, MicroControl offers training, workshops, and technical consulting on CAN, CANopen, and CANopen FD.

• Basic and intensive training courses on CAN and CANopen – ideal for development teams and students who want to quickly build up practical know-how.
• Project-support workshops, e.g. for defining network architectures, PDO mappings, or integrating safety functions.
• Engineering support for porting the stacks to new target hardware, commissioning CANopen networks, or analyzing issues in the field.

This makes MicroControl not just a supplier of protocol software, but a full-service partner for CANopen projects – from the initial concept phase through implementation all the way to series support.