CANopen is a CAN-based communication system. It comprises higher-layer protocols and profile specifications. CANopen has been developed as a standardized embedded network with highly flexible configuration capabilities. It was designed originally for motion-oriented machine control systems, such as handling systems. Today it is used in various application fields, such as medical equipment, off-road vehicles, maritime electronics, railway applications, or building automation.

CANopen unburdens the developer from dealing with CAN hardware-specific details such as bit timing and acceptance filtering. It provides standardized communication objects (COB) for time-critical processes, configuration as well as network management data.

"Plug and play" with CANopen

Standardized CANopen device and application profiles simplify the task of integrating a CANopen system. Off-the-shelf devices, tools, and protocol stacks are widely available at reasonable prices. For system designers, it is very important to reuse application software. This requires not only communication compatibility, but also interoperability and interchangeability of devices. CANopen device, interface, and application profiles enable device manufacturers to provide their products with standardized interfaces to achieve CANopen devices with "plug and play" capability in CANopen networks. Nevertheless, CANopen allows implementing manufacturer-specific functionalites.

CANopen at a glance

CANopen provides several communication objects, which enable device designers to implement desired network behavior into a device. With these communication objects, device designers can offer devices that can communicate process data, indicate device-internal error conditions or influence and control the network behavior. In their products, device designers may also support CANopen functions that enable the devices to participate in point-to-point communication coherences in the network. As CANopen defines the internal device structure, the system designer knows exactly how to access a CANopen device and how to adjust the intended device behavior.

CANopen lower layers

CANopen is based on a data link layer according to ISO 11898-1. The CANopen bit timing is specified in CiA 301 and allows the adjustment of data rates from 10 kbit/s to 1000 kbit/s. Although all specified CAN-ID addressing schemata are based on the 11-bit CAN-ID, CANopen supports the 29-bit CAN-ID as well. CANopen assumes a physical layer according to ISO 11898-2. Nevertheless, CANopen does not exclude other physical layer options.

Further information on the CANopen lower layers is available here.

Internal device architecture

A CANopen device consists of three logical parts. The CANopen protocol stack handles the communication via the CAN network. The application software provides the internal control functionality as well as the interface to the process hardware interfaces. The CANopen object dictionary interfaces the protocol as well as the application software. It contains references (indices) for all used data types and stores all communication and application parameters.

The CANopen object dictionary is most important for CANopen device configuration and diagnostics. As device-internal reference, a 16-bit index which is given as 4-digit hexadecimal value, is used. The index range 1000_h to 1FFF_h provides references to all parameters that determine the CANopen communication behavior of the CANopen device. The index range 2000_h to 9FFF_h provides the references to all application-related parameters. CANopen distinguishes between proprietary parameters (index range 2000_h to 5FFF_h) and standardized parameters (index range 6000_h to 9FFF_h).

Further information on CANopen internal device architecture is available here.

CANopen protocols

A CANopen protocol stack implements several CANopen COBs that are communicated with one of the CANopen bit-rates. The CANopen communication objects enable system designers to transfer control information, to react to certain error conditions or to influence and control the network behavior. The capability of CANopen devices can be evaluated by checking the existence of the related CANopen object dictionary entries that describe the communication behavior.

The CANopen protocols comprise:

SDO Protocol
PDO Protocol
NMT Protocol
Special Function Protocols
Error Control Protocol

A. Service data object (SDO)

Service data objects (SDOs) enable access to all entries of a CANopen object dictionary. One SDO consists of two CAN data frames with different CAN-Identifiers. This is a confirmed communication service. With an SDO, a peer-to-peer client-server communication between two CANopen devices can be established on the broadcast medium CAN. The owner of the accessed object dictionary acts as a server of the SDO. The device that accesses the object dictionary of the other device is the SDO client.

Variants of the SDO protocol

A CANopen device can support different variants of the SDO protocol:

The expedited transfer,
the normal (segmented) transfer, or
the block transfer.

During this initiation, the client device indicates which information is going to be accessed from the server's object dictionary, which SDO type is used, and if the information is to be read or written. The server device acknowledges the inquiry and the client device then starts to transmit the first data segment. The normal transfer allows to communicate any amount of data in a segmented way. Each segment can carry up to seven byte of application data, as one byte of the CAN frame is required for protocol information. In normal SDO transfer (see figure) an unlimited number of segments and therefore of application data can be exchanged.

To speed up an SDO transfer of small amounts of data (less or equal 4 byte), the expedited SDO transfer can be used. In such an SDO connection, the data is directly transferred during the initiation of the SDO connection. Speeding up the transmission of huge amounts of data can be achieved by supporting the SDO block transfer. During the block transfer, no single data segment (like during the normal transfer) but only a block of data (up to 127 segments) is confirmed by the receiver.

Device manufacturers should base their choice of SDO variant on the amount of data that a device is going to communicate.

SDO channels

A CANopen device may support SDO client or server channels. In case a device supports SDO client channels, the device is able to access the object dictionaries of other network participants. By supporting server channels, device manufacturers give other network participants the opportunity to access object dictionary entries on their device. Device manufacturers must evaluate whether their device needs to access other devices (e.g. a controller that configures other network participants) or whether other devices have to access their device (e.g. for configuration purposes). After this evaluation, device manufacturers can assess how many SDO client and server channels will be required. The first SDO server channel is strictly predefined by the specification and has to be supported by all CANopen devices.

SDO parameter set

The SDO parameter sets are arranged in the object dictionary index range 12xx_h. The SDO server channels are described in the range from 1200_h to 127F_h. The parameter sets of the client channels have to be provided in the range from 1280F_h to 12FF_h. A SDO parameter set contains the two communication object identifiers (COB-IDs) and the node-ID of the related communication partner. The COB-ID entries cover the CAN-Identifiers of the CAN frames used to transmit information in the direction "server to client" and vice versa.

B. Process data object (PDO)

Process data objects (PDOs) are used in CANopen for broadcasting high-priority control and status information. A PDO consists of a single CAN frame and communicates up to 8 byte of pure application data. Device designers have to evaluate the amount of process data that the device needs to receive and transmit. Based on the result of this evaluation process, they have to provide the related amount of receive and transmit PDOs within the device.

PDO parameter sets

In case a device is supposed to support the transmission/reception of a PDO, the corresponding parameter sets for this PDO have to be provided in the object dictionary of that device. A single PDO requires a set of communication parameters (PDO communication parameter record) and a set of mapping parameters (PDO mapping record).

Among others, the communication parameters indicate the CAN-Identifier that is used by this PDO, and the triggering event that prompts the transmission of the related PDO. The mapping parameters indicate which information of the local object dictionary is supposed to be transmitted and where the received information is to be stored.

The communication parameters for receive PDOs are arranged in the index range 1400_h - 15FF_h and for transmit PDOs in the range 1800_h - 19FF_h. The related mapping entries are managed in the index ranges 1600_h -17FF_h and 1A00_h - 1BFF_h.

PDO triggering events

The following triggering events for PDOs are defined:

Event- or timer-driven: A device-internal event triggers the PDO transmission (e.g. when the temperature value exceeds a certain limit; event-timer elapses; etc.).

Remotely-requested: As PDOs consist of a single CAN data frame, they can be requested via remote transmission request (RTR).

Synchronous transmission (cyclic): The transmission of the PDO can be coupled to the reception of the SYNC message.

Synchronous transmission (acyclic): These PDOs are triggered by a defined device-specific event but transmitted with the reception of the next Sync message.

PDO mapping

PDO mapping defines which application objects are transmitted within a PDO. It describes the sequence and length of the mapped application objects. The mapping of the application objects is described in the related CANopen object dictionary entries for each PDO. CANopen distinguishes between three types of PDO mapping:

Static PDO mapping: In case static mapping is supported for a PDO, the content of the PDO is strictly predefined by the device manufacturer and cannot be changed via the CANopen interface.

Variable PDO mapping: Variable PDO mapping describes that the mapping entries of a PDO can be changed during NMT pre-operational state.

Dynamic PDO mapping: A device supports dynamic mapping if the PDO mapping entries in the CANopen object dictionary can be changed during NMT operational state as well.

PDO mapping procedures

In contrast to a strictly pre-defined mapping, device designers have the option of offering to change the mapping of the PDOs. In CANopen such a flexibly-adjustable PDO mapping capability is called variable or dynamic PDO mapping. In case variable or dynamic mapping is supported, the mapping entries of the PDO can only be changed by using the defined mapping procedure:

Set PDO invalid by switching Bit 31 in the related COB-ID entry.
Set PDO mapping invalid by writting 00_h to sub-index 00_h of the related mapping entries.
Adjust the desired PDO mapping.
Set sub-index 00_h of the related mapping index to number of mapped objects.
Switch PDO valid by means of Bit 31 in the related COB-ID entry.

C. Network management (NMT)

All CANopen devices must support the CANopen network management (NMT) slave state machine. The NMT state machine defines the communication behavior of a CANopen device. The CANopen NMT state machine consists of an Initialization state, a Pre-operational state, an Operational state, and a Stopped state. After power-on or reset, the device enters the Initialization state.

After the device initialization is finished, the device automatically transits to Pre-operational state and indicates this transition by sending the boot-up message. This way the device indicates that it is ready to work. A device that stays in Pre-operational state can start to transmit SYNC-, Time Stamp- or Heartbeat messages if these services are supported and configured in the right way. In contrast to PDO communication that has to be disabled in this state, the device can communicate via SDO. PDO communication is only possible in the Operational state. During Operational state, the device can use all supported communication objects. A device that was switched to the Stopped state only reacts to received NMT commands. In addition, the device indicates the current NMT state by supporting the error control protocol during Stopped state.

Initilization state

The Initialization state covers the three substates Initialising, Reset Application, and Reset Communication. During Initialising, the device starts up and initializes its internal parameters. The two substates Reset Application and Communication were introduced to enable partial reset commands. During Reset Application all parameters in the object dictionary range from 2000_h to 9FFF_h are set to the power-on or default values. After setting the power-on values, the NMT substate Reset Communication is entered autonomously. During the Reset Communication substate, the parameters of the communication profile (Index range 1xxx_h) are set to their power-on/default values. After this state, the Initialization state is left.

NMT protocol

The NMT protocol is transmitted by the active NMT master in a CANopen network. The reception of the NMT protocol forces the CANopen device to transit to the commanded NMT state. The NMT protocol comes in a single CAN frame with a data length of 2 byte. The first byte contains the command specifier and the second contains the Node-ID of the device that has to perform the command (if this value is equal to 0, all nodes have to perform the commanded state transition). The NMT protocol comes with the CAN-Identifier 0, the highest prior CAN-ID in a CAN-based system.

D. Special Function Protocols

CANopen offers three specific protocols for generating a special network behavior:

The SYNC protocol enables synchronous network behavior.
The Time-stamp protocol is used for the adjustment of a unique network-time.
The Emergency protocol can be used to inform other network participants about device-internal errors.

Synchronisation (SNYC) protocol

The SYNC protocol is transmitted periodically by the SYNC producer. The time period between two consecutive SYNC messages is the communication cycle period. The SYNC message is mapped to a single CAN frame with the identifier 80_h according to the predefined connection set. By default, the SYNC message does not carry any data (DLC = 0). Devices that support CiA 301 Version 4.1 or higher may optionally offer a SYNC message, which provides a 1 byte SYNC counter value. Therefore synchronous behavior of several devices can be coordinated more comfortably.

Emergency protocol

The Emergency messages are triggered by a device-internal error. The Emergency message, transmitted by the Emergency producer, is mapped to one single CAN frame, which covers up to eight byte of data. The data content is defined as a 1 byte Error register (Index 1001_h of the local object dictionary), a 16-bit Emergency error code, and up to 5 byte of manufacturer-specific error information. By default, a device that supports the Emergency producer functionality assigns the CAN-Identifier 80_h + (node-ID) to the Emergency message. An Emergency message is transmitted only once per error event. As long as no new errors occur on a device, no further emergency messages are transmitted. Zero or more Emergency consumers may receive these messages and may initiate suitable, application-specific counter measures.

Time-stamp protocol

The Time-stamp protocol enables the user of CANopen systems to adjust a unique network time. The Time-stamp is mapped to one single CAN frame with a data length code of 6 byte. These six databytes provide the information "Time of Day". This information is given as milliseconds after midnight (Datatype: Unsigned28) and days since January 1, 1984 (Datatype: Unsigned16). The associated CAN frame has by default the CAN-Identifier 100_h.

E. Error Control Protocols

Error control protocols enable the monitoring of a CANopen network. They comprise the Heartbeat-, Node-/Life-Guarding-, as well as the Boot-up protocol. The Heartbeat protocol is used to verify that all network participants are still available in a CANopen network and that they are still in their intended NMT FSA state. In old-fashioned CANopen systems, the CAN remote frame-based Node-/Life-guarding protocol is used for this purpose, instead of the Heartbeat protocol. CAN in Automation no longer recommends using CAN remote frame-based services. All error control protocols are based on the same CAN message with the CAN-ID 700_h + Node-ID of the CANopen device that are to be monitored.

Heartbeat protocol

The Heartbeat protocol is a cyclically transmitted message that informs all heartbeat consumers of the availability of the heartbeat producer. In addition to the availability of the heartbeat producer, the heartbeat protocol provides the current NMT FSA state of the heartbeat producer. The cycle time for transmitting the Heartbeat message is configurable in the object dictionary index 1017_h.

Boot-up protocol

The boot-up protocol represents a special type of an error control protocol. It is transmitted as the final action in NMT FSA state Initialisation, prior to enter the NMT FSA state Pre-operational. The reception of this message indicates that a new device has been registered to the CANopen network. The unintended reception of such a protocol during runtime either indicates a change in the network setup (e.g. due to the addition of a new CANopen device) or is considered a sign for an error condition (e.g. erroneous power supply of related CANopen device). The protocol uses the same identifier as any other error control protocol, such as e.g. the heartbeat protocol. The 1-byte data field has a fixed value of zero.

Node-/Life guarding protocol

Guarding is an outdated method of checking whether a guarded CANopen device is still working in the correct network state. As this is an RTR-based service, the Heartbeat protocol is used in new designs. In old-fashioned applications, the host controller triggers the error control information of the monitored CANopen devices via the CAN remote frame (RTR) for example. Each monitored CANopen device has to be triggered individually. The monitored device replies with a CAN data frame that indicates the current NMT FSA state.