CANopen
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.
Advantages
- 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
Fundamentals
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.
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) | Object |
0000 | not used |
0001-025F | Data Types |
0260-0FFF | Reserved for further use |
1000-1FFF | Communication Profile Area |
2000-5FFF | Manufacturer Specific Profile Area |
6000-9FFF | Standardized Device Profile Area |
A000-AFFF | Network variable area |
B000-BFFF | System variable area |
C000-CFFF | Reserved for further use |
Communication Principles
There are two fundamental types of communication on a CANopen bus.
SDO
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.
PDO
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.
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).
Specification
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.
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.
| Tools | |
|---|---|
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.
Bus System | Interface | PC Connection |
|---|---|---|
CAN, CAN FD, LIN and J1708: | USB (RT PC) PCIe | |
Ethernet and CAN / CAN FD: | USB | |
FlexRay and CAN / CAN FD: | USB (RT PC) | |
* = not CAN FD capable
Additional Information
Do you have technical questions and are you looking for suitable answers? Our knowledge base provides the most important FAQs for you.