CANopenCAN-based Communication System
Navigation de page
- Début de la page
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
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.
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).
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
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.
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).
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
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:
Analysis of CANopen networks:
Project planning and configuration of CANopen networks:
EDS Editor for CANopen:
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.
CAN, CAN FD, LIN and J1708:
USB (RT PC)
Ethernet and CAN / CAN FD:
FlexRay and CAN / CAN FD:
USB (RT PC)
* = not CAN FD capable