An In-Depth Understanding of the CANopen Protocol

The CANopen Protocol is one of the most popular and widely adopted standards in the field of industrial automation. As an open and standardized industrial CAN bus protocol, it allows devices to exchange data seamlessly and efficiently in a real-time fashion. Offering different CANopen communication mechanisms suitable for different applications and use cases, the CANopen Protocol is used in building automation systems, commercial vehicles, medical equipment, maritime applications, railway systems, and more. The standard is managed by CAN in Automation (CiA) International Users and Manufacturers Group and is standardized as EN 50325-4. In this article, we will provide a comprehensive introduction to the CANopen Protocol, exploring its various facets and shedding light on its internals.

CANopen Protocol OSI Layer Mapping

To understand how the CANopen Protocol operates, it is essential to grasp its mapping to the OSI (Open Systems Interconnection) model. The OSI model is a conceptual framework that defines the functions of a communication system.

CANopen OSI Layer Mapping

The CANopen Protocol, being a higher-level protocol, primarily operates at the application layer of the OSI model. It utilizes the services provided by the data link layer using the standard CAN bus, to establish communication between devices. Without the overhead of intermediate layers, CANopen is quite easy to implement and offers real-time performance. On top of the CANopen communication framework, device profiles are supported, which will be covered later here.

CANopen Message Structure

The CANopen Protocol utilizes a structured message format to facilitate CANopen communication between devices as captured below.

CANopen Message Format

Each message consists of a CAN identifier, indicating the type of message and the device it is intended for. The 11-bit standard CAN ID is split into 4-bit function code and 7-bit node ID. The function code indicates the type of protocol payload being carried over the data part. The message payload contains the actual data being transmitted, to be decoded based on the function code.

CANopen Device Architecture

The CANopen Protocol specification defines a standard device model that can be implemented by devices intended for any application. The CANopen device model is depicted in the below picture.

CANopen Device Model​

The communication module takes care of the different types of protocols supported in the CANopen device.

The CANopen Object Dictionary contains references (indices) of all data types, communication, and application parameters. It is the central data store that all modules in the device interact with, and every node on a CANopen network must expose a conforming CANopen Object Dictionary to enable interoperability.

The application module is the interface to the actual function implementation of the device and updates the object dictionary.

Communication Protocols in CANopen

On top of the CAN bus as the underlying communication medium, the CANopen Protocol supports various communication protocols. These protocols provide additional functionality and features to the CANopen network. Some of the commonly used communication protocols in CANopen include PDO (Process Data Object), SDO (Service Data Object), NMT (Network Management), and SYNC (Synchronization). Each protocol serves a specific purpose, such as real-time data exchange, configuration and parameterization, network management, and synchronization of devices. The availability of these protocols enhances the versatility and adaptability of the CANopen Protocol in different industrial automation applications. If you are building protocol-aware firmware for industrial devices, our product engineering services cover the full stack from CANopen node implementation to system-level integration.

This protocol enables direct access to the server's object dictionary. Both read and write operations are supported. Typically, at least one SDO channel must be supported by each CANopen device for practical use.

Process data enables real-time transfer of data such as the inputs from sensors and outputs of the node device. While SDO is a request/response mechanism, PDO does not call for acknowledgement and the frame length can be flexible. The PDOs have lower CAN IDs to have higher priority than SDOs. A transfer PDO (TPDO) represents the data originating from a node and receive PDO (RPDO) is the data being consumed by the node.

NMT protocol enables control of communication state of each node. Each of them can be started, stopped or reset. Based on the state of the CANopen node, the other protocols are allowed/disallowed.

Apart of the above protocols, CANopen offers specific protocols:

• SYNC protocol for synchronization of network nodes and process data
• Emergency Objects for error messages handling
• Time stamp protocol for adjustment of unique network-time

With support for Heartbeat protocol, Node-/Life-Guarding protocol, and the Boot-up protocol, enable the monitoring of a CANopen network.

CANopen Object Dictionary

The CANopen Object Dictionary is a key component of the CANopen Protocol. It serves as a repository of data objects that devices in the network can access. The functional features supported by the node must be exposed via an object. Each object is associated with a 16-bit index that is unique and pre-defined. Each object has an attribute that specifies if it is read/write, read-only or write-only. The data type of the object is also specified. If it is a composite variable, an 8-bit sub-index can be used to identify the field inside the structure.

The CANopen Object Dictionary index space is divided into well-defined regions, as shown in the table below. Interoperability between devices from different manufacturers depends on both parties correctly populating the shared regions of the CANopen Object Dictionary.

Communication Mechanisms in CANopen

The CANopen Protocol provides different CANopen communication mechanisms that determine how devices interact with each other. These mechanisms include Client/Server, Master/Slave, and Producer/Consumer models. In the Client/Server model, a client device sends a request to a server device, which then processes the request and sends a response back to the client. The Master/Slave model involves the master device controlling the exchange of data with the slave devices. Finally, the Producer/Consumer model allows devices to asynchronously exchange data, enhancing the flexibility and efficiency of communication in the CANopen network. With this wide range of CANopen communication mechanisms, different types of networks can be created based on the application needs. Teams deploying the CANopen Protocol across machine fleets can benefit from proven industrial automation expertise to ensure each node is configured, profiled, and validated correctly.

CANopen Device Profiles

CANopen Device Profiles define the specific behavior and functionality of devices in a CANopen network. These profiles outline the mandatory and optional features that a device must support to ensure interoperability with other devices. CANopen Device Profiles provide a standardized way for manufacturers to design and implement devices that are compatible with the CANopen Protocol. By adhering to these profiles, device manufacturers can ensure seamless CANopen communication and integration of their devices into a CANopen network.

Standardized profiles include the communication profiles (e.g., DS 301, DS 302) that specify how the node must behave over the network.

The CANopen Device Profiles define the specific class of functional devices such as

As against the device profile that specifies the particular node, the CiA application profile specifies the entire network. It could define virtual devices to enable proper functionality of the entire system.

Conclusion

The CANopen Protocol remains one of the most versatile and widely adopted industrial CAN bus protocols for real-time CANopen communication in automation networks. Its layered architecture — combining a well-structured CANopen Object Dictionary, flexible CANopen Device Profiles, and a rich set of communication mechanisms — gives engineers the building blocks to create interoperable, deterministic systems across industrial, medical, and transportation domains. Embien’s digital transformation and cloud infrastructure services extend CANopen-enabled systems with scalable connectivity, data integration, and remote monitoring capabilities.