RT-CANopen architecture


List of abbreviations

List of abbreviations used in the document


Controller Area network


Communication object (CAN message). A unit of transportation in a CAN network. Data must be sent across a network inside a COB.



Unique ID of the COB. The identifier determines the priority of the COB in the MAC sub-layer too.


Electronic Data Sheet


Finite State Machine

CANopen FSM in this article means a state automat processing CAN messages.


Handlers Definition Sheet


Network ManagemenT

COBs designated for network management ie. initialize, start, stop nodes etc.; this service is implemented according to master-slave concept.


Object Dictionary

Common representation of device parameters, process variables, configuration, communication settings and device data types. Accesible as SDO objects from CANopen network. The textual description of OD is called EDS file.


Process Data Object

CANopen objects designed for real-time process data exchange.


Receive PDO

PDO received by device in order to set appropriate PDO mapped objects value.


Remote Transmission Request

CAN message to initiate RPDO object sending.


Service Data Object

CANopen service objects designated for manipulation with slaves object dictionaries.


Special Function Object

Special purpose messages ie. SYNC, time stamp, emergency, node/life guarding, boot-up objects.


Transmit PDO

PDO transmitted by device when device specific event occurs (ie. timer or object value is changed) or as a response to the RTR or after SYNC object.


Virtual RT-CAN API

* - this abreviations are not standardised yet and they are valid only in OCERA project


Virtual CAN API (VCA)

The virtual CAN API is the interface to connect application thread either with the CAN hardware card or with other software layers substituting CAN bus. The application thread can be in RT_Linux/kernel space or in the user space.

User space VCA usage

In Figure 8-9 the application thread and CAN driver reside in different address spaces. To connect kernel space and user space, we use device /dev/can xx. The applications which will not use VCA can use directly /dev/can and the standard set of I/O operations (read, write, ioctl). A libCAN is needed to grant the same API to user space and kernel space threads. This approach supports portability of application threads between the kernel and user spaces on the source code level.

CAN bus substituting layer with VCA

On Figure 8-10 we can see option, that gives us an opportunity to exploit the VCA even if no real CAN hardware is used. This solution is designed mainly for development purposes and testing. The dashed line in the figure means that CAN substitution layer can optionally operate on some other device than /dev/can (ie. Ethernet). CAN substitution layer can be also a kind of user space application providing the VCA. This can be very useful during development or for educational purposes.

RT-CANopen slave


RT-CANopen slave (only slave or CANopen slave will be used instead in rest of this section) is the software solution based on the hardware, RT-CANopen FSM threads, EDS file and HDS file (see Figure 8-11).

CANopen slave components description

Slave FSM: Slave FSM means set of RT-Linux threads providing PDO and SDO communication via CAN driver VCA. Slave FSM also calls appropriate handler PDO communication and looks into the slave's object dictionary in case of SDO request.

PDO handlers: User written module containing handlers for reading/writing PDO mapped object data from/to hardware.

EDS: EDS means the Electronic Data Sheet, text file describing all objects in the slave object dictionary. EDS is parsed in order to create the slave OD.

HDS: HDS means the Handler Definition Sheet, text file describing the linking PDO's COB-ID with required handler in order to grant correspondence between the CANopen object value and technological process data from the hardware. For example a thermometer with the analog output connected to PC A/D convertor card needs handler which reads temperature from the card output port and gives it to the FSM. The slave designer have to write this handler code while the FSM source code remains always the same, OCERA written.

User space OD slave architecture

As can be seen on figure above CAN driver sends the CAN messages to CANopen FSM via VCA. FSM handles messages of two main categories, process data (PDO) and service data (SDO, NMT, SFO).

The process data (PDO objects) are handled separately of the service ones. Slave FSM exploits CAN driver message buffers as the buffers for the slave PDOs. This approach is necessary because some CAN chips have such buffers integrated. On the other hand this can speed up PDO object handling. Slave FSM role lies in updating this buffers after device specific event such is timer event or process object value change. The CAN driver sends objects from its buffers when needed (after SYNC object or as a response to RTR object). Consequently slave FSM has to read this buffers after WPDO object arrival.

The PDO handler module is used to synchronize PDO mapped objects values and real world data examined or set by computer hardware. Every PDO mapped object has assigned its reading and writing routine called PDO handler. These handlers are written by control system developer in order to fit general FSM concept to specific hardware and real world process.

Some of SFO are handled directly by CAN driver. Such objects are the SYNC or RTR frames

Other objects (SDO, NMT) are sent through the SDO API to OD driver. OD driver is responsible for all object dictionary manipulations, that means getting and setting object values. If the PDO mapping change occurs due to SDO object processing, OD driver informs slave FSM (via SDO API) to correct PDO handlers table to reflect PDO mapping status in OD properly.

OD driver communicates with OD daemon, which resides in the user space, through RT FIFOs. OD daemon offers set of primitives to provide basic manipulations with OD like get/set object value, add object, delete object etc. OD daemon also owns slave OD in its memory space.

Slave OD can be loaded onto OD daemon memory by EDS parser. EDS parser is the graphical front end to the OD daemon connected with it via Unix socket. This gives us the opportunity to control the daemon and slave OD remotely using TCP/IP. EDS parser is also responsible to read HDS and make appropriate changes in daemon OD and also (via daemon SDO API) in slave FSM PDO handler table. This ensures that the proper handlers will be called for certain PDO objects.

For diagnostic and visualization purposes the diagnostic couple of pipes exists. This pipes can be connected to the diagnostic and monitoring application.

RT-CANopen master architecture

RT-CANopen master architecture is very similar to the user space slave one. CAN driver, FSM, OD driver and OD daemon are the same. New blocks, PDO processor and PDO object table are introduced and OD daemon contains OD of all slaves connected till now.

PDO objects table is a memory mirror for transmitted and received PDOs. When a new RPDO comes, it is written into the table and PDO processor is notified by master FSM about this event. On the contrary, when PDO processor updates some object in the write part of PDO table, the FSM should be notified to allow it to transmit object change across the network.

PDO processor is an user written set of functions designated for processing objects from read part of PDO table and generating new value of objects in write part of PDO table. New generated write objects can be sent across the CAN, if the processor notifies master FSM. This way the RPDO-TPDO mapping rules or control algorithms can be realized.

We expect to design PDO processor as a special PDO handler (from slave FSM point of view). This approach gives us the opportunity to have the same FSM for slave and master.

The master OD daemon holds one or more slave EDS. That means, that the slave OD daemon is a special case of the master one. Thanks to this generalization we can have also one code for the master and slave OD daemon.

When we look at the paragraphs above, we can see, that the User space CANopen slave and the CANopen master share the same code, which can be any time configured to run as a master or as a slave.


The RT-CANopen architecture design is based upon 4 basic elements.

The Virtual CAN API introduces either real CAN network or any substitution of that sublayer to the application threads. Application threads can reside in user space or in kernel/RT-Linux space.

The CANopen FSM is an kernel space state machine connected to VCA, which can handle the process data (PDOs) and service data (SDO, NMT, SFO). The PDOs are handled by PDO handler functions. The service data objects are resent through a SDO API to OD driver for other processing and its response is sent back if necessary.

The OD driver manages a device OD. It is also able to communicate with FSM via EDS API to provide it information about every particular object. The OD driver can be realized either whole in the kernel space or partially in the user space (OD daemon).

The EDS parser serves for processing EDS and configuration files. Processed data are loaded into OD daemon (master, user space slave). EDS parser can also generate OD driver module source code in C (kernel slave concept).

This philosophy gives us the opportunity to reuse common elements to build the CANopen master or slave even to define it in process of configuration.


[CANOpen] CiA CANopen - Application Layer and Communication Profile, CiA Draft Standard 301 CAN in Automation e. V. 1 June 2000

[[EDS]] CiA, CANopen: Electronic Data Sheet Specification for CANopen, CiA Draft Standard Proposal 306, CAN in Automation e. V., 31 May 2000.

[[CANBus]] H. Boterenbrood, CANopen: high-level protocol for CAN-bus, NIKHEF, Amsterdam, 20 Mar 2000.