The CANopen protocol is one of the popular and widely adopted in the field of industrial automation. As an open and standardized communication protocol, it allows devices to exchange data seamlessly and efficiently in a real time fashion. Offering different communication mechanisms that are suitable for different applications and use cases, it is used in building automation systems, commercial vehicles, medical equipment, maritime applications, railway systems, etc. 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 to 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 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 indicated 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 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.
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.
SDO (Service Data Object) protocol: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.
PDO (Process Data Object) protocol: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 (Network Management) protocolNMT 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.
Special function protocolsApart 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 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.
| Start Index | End Index | Object Group |
|---|---|---|
| 0x0000 | 0x0000 | Reserved |
| 0x0001 | 0x009F | Static and complex data types |
| 0x00A0 | 0x0FFF | Reserved |
| 0x1000 | 0x1FFF | Communication profiles |
| 0x2000 | 0x5FFF | Manufacturer-specific |
| 0x6000 | 0x9FFF | Standardized device profiles |
| 0xA000 | 0xFFFF | Reserved |
Communication Mechanisms in CANopen
The CANopen protocol provides different 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 communication mechanisms, different types of networks can be created based on the application needs.
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. 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 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 device profiles define the specific class of functional devices such as
| Number | Name |
|---|---|
| CiA 401 | Profile for I/O devices |
| CiA 402 | Profile for drives and motion control |
| CiA 404 | Profile for measuring devices and closed-loop controllers |
| CiA 406 | Profile for encoders |
| CiA 408 | Profile for fluid power technology proportional valves and hydrostatic transmissions |
| CiA 412 | Profiles for medical devices |
| CiA 419 | Profile for battery chargers |
| CiA 442 | Profile for IEC 61915-2 compatible motor starters |
| CiA 452 | Profile for PLCopen motion control |
| CiA 458 | Profile for energy measurements |
| CiA 461 | Profile for weighing devices |
| CiA 462 | Profile for item detection devices |
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.
| Number | Name |
|---|---|
| CiA 415 | Profile for sensor systems in road construction and earth moving machines |
| CiA 416 | Profile for building door control |
| CiA 417 | Profile for lift control systems |
| CiA 423 | Profiles for rail vehicle power drive systems |
| CiA 426 | Profile for rail vehicle exterior lighting control |
| CiA 434 | Profile for laboratory automation systems |
| CiA 447 | Profile for special-purpose car add-on devices |
| CiA 454 | Profile for energy management systems |
| CiA 455 | Profile for drilling machines |
Conclusion
In conclusion, the CANopen protocol is a powerful tool for achieving seamless communication in industrial automation environments. By understanding its various aspects, from the message structure to the communication mechanisms and device profiles, professionals in the field can harness its power to create efficient and reliable automation systems. Look forward to this space for more information about such important industrial protocols.
