CANopen is the standardized CAN-based network for embedded applications (EN 50325-4). It was originally developed for motion-oriented machine control networks, e.g. handling machines, packaging machines, conveyor belts, assembling, and printing machines. By now it is being used to network medical electronics, automotive-, industrial- and rail-vehicles, laboratory automation systems, building automation systems, maritime control systems, and many other embedded networks such as passenger information systems, and even in gambling machines and professional coffee machines. CANopen also may be used for very deeply embedded communication (e.g. open backplane bus). The web site of the CAN in Automation (CiA) international users' and manufacturers' group lists a many application examples at www.can-cia.org.

CANopen system designers benefit from the easy integration of CANopen-compliant devices into their systems. It is also possible to integrate CAN layer-2 devices as well as to integrate CANopen devices into proprietary CAN network solutions. One of the most important advantages is the availability of off-the-shelf CANopen tools for development, testing, configuration, and maintenance. In addition, off-the-shelf CANopen protocol stacks are available for a wide variety of CAN controllers and micro-controllers. Another advantage of CANopen is the availability of the CANopen conformance test tool. Not only device designers may use this tool, but also a system designers may test purchased devices with it. CiA headquarters uses the very same tool for certification purposes.

The CANopen higher-layer protocol is non-proprietary. The CANopen application layer and communication profile (EN 50325-4) supports direct access to device parameters and transmission of time-critical process data. The CANopen network management services simplify project design, system integration, and diagnostics. The CANopen application layer specifications (CiA 301, CiA 302, and CiA 303) cover application layer and communication profile, the framework for programmable devices, as well as recommendations for cables and connectors and SI units and prefix representations. Some of the CANopen device, interface and application profiles are available for free; some however are reserved for members of CiA.


The CANopen protocol
In every decentralized control application, different communication services and protocols are required. Therefore the CANopen protocol provides standardized communication objects for real-time data (process data objects, PDO), for configuration data (service data objects, SDO), and network management data (boot-up message, NMT message, and error control messages) as well as other functions (Time Stamp, Sync message, Emergency message). All communication objects are accessible via the CAN network in the device's Object Dictionary. These objects are addressable by a 16-bit index. In the case of Array and Record objects there is an additional 8-bit sub-index. The total is a 24-bit addressing scheme.

Object Dictionary

The Object Dictionary describes the functionality of a device. It does so by describing the communication objects (application data and configuration data) in a specified way. The Object Dictionary is the interface between the CAN communication interface and the application program. The Object Dictionary is unique for every CANopen device.

Process Data Objects (PDO)

Real-time data is exchanged in process data objects (PDO). PDOs are mapped to a single CAN frame and use up to 8 bytes of the data field to transmit application objects. Each PDO has an identifier and is transmitted by only one node in the network. It is received by more than one node however (producer/consumer communication). PDOs may be triggered by an internal event (e.g. the temperature rises over a specified number), by an internal timer, by a remote request and the Sync message. The Object Dictionary describes the default mapping of application objects for each PDO as well as the supported transmission mode. PDO transmission is not confirmed. High-priority PDO messages are assigned a low identifier number to ensure prioritized bus access.

Service Data Objects (SDO)

A device is configured with Service Data Object (SDO) messages. SDOs read or write entries from and to the Object Dictionary. The SDO protocol can transmit objects of any size by segmenting the content of the message. SDO transmission is a confirmed service.

Network Management (NMT)

Since CANopen is suitable for decentralized architectures, no single master device necessarily exists in the network. This means that at least one device must perform the Network Management (NMT). NMT objects include the Boot-up message, the Heartbeat protocol, and the NMT message. When the NMT master of a CANopen network transmits the NMT message, all other devices transit to another NMT state. States can be Initialization, Pre-operational, Operational, and Stopped. SDO messages are only allowed in the Pre-operational state. PDO messages are allowed in the state Operational.

Additional services

The Boot-up message is sent by a device when it boots-up or after a power-out during operation. It is sent to the CANopen NMT master to indicate that the device has reached the state Pre-operational. By sending a Heartbeat message a device indicates that it is working properly. It signals its presence and its current state by sending this periodic message to a specific device or to several ones. CANopen also defines protocols for synchronization, emergency indication and time-stamping. To enable all devices in the network to synchronize to the same clock, a Sync producer in the network periodically broadcasts the Sync message. If an error occurs inside a device, it will trigger the device to transmit the Emergency message to the corresponding application device. Some applications require a time-stamping of messages. The CANopen time-stamping protocol enables this, too.


System design

Allocation of CAN identifiers to the COBs (communication object) is an essential issue in system design as CAN is a COB-oriented network. Each COB has one or more associated identifiers, which implicitly specifies its priority. In order to reduce configuration effort for simple CANopen networks, a mandatory default-identifier allocation scheme is defined. These CAN identifiers are available in the Pre-operational state and may be modified by means of dynamic distribution. A CANopen device has to provide the corresponding CAN identifiers only for the supported communication objects. The default profile ID-allocation scheme consists of a functional part, which determines the object priority and a node-ID-part, which allows distinguishing between devices with the same functionality. The ID-allocation scheme corresponds to a pre-defined master/slave connection set and allows peer-to-peer communication between a single-master device and up to 127 slave devices. It also supports the broadcasting of unconfirmed NMT, Sync and Time-Stamp messages. In order to optimize the CAN identifier allocation, the system designer may configure the allocation of identifiers to communication objects.


CANopen additional application layer functions

The CiA 302 specification defines additional functionalities and mechanisms besides the standard mechanisms defined in CiA 301. Additional functionalities are needed for so-called intelligent CANopen devices. Such additional functionalities are CANopen managers, multiple NMT masters in one CANopen network, plug-n-play CANopen networks, redundant networks for mission-critical use, or application program download and control.
Within a distributed system the application process is divided into several parts running on different CANopen devices. From the applications point of view usually one CANopen device is responsible for the control of the system. This CANopen device is called application master (e.g. a PLC). From the network's point of view there are several additional functionalities, which not directly deal with the application but provide application-supporting functions. These additional functionalities are based on a master / slave, client / server or producer / consumer relationship. As it is common to combine several of the additional functionalities in one CANopen device the term CANopen Manager is introduced. A CANopen device is referred to as CANopen manager if it provides the NMT master and at least one of the functionalities SDO manager or Configuration manager.


CANopen safety protocol

The CANopen safety protocol (CiA 304) is approved for safety-relevant communication. It is based on a serial redundancy concept, which means that safety-relevant information is transmitted in two independent CAN messages (CAN identifiers differ at least by in two bits). The data in the second message is bit-wise inverted and is cross-checked after re-inversion with the first message in the consuming device.