Understanding CAN Protocols I


This is the first article in a serie about CANBus and higher-level protocols, which are extensibily used in Industrial environtmens along with Embedded Systems.

CANBus standard describes only the layer 1 and 2, from an OSI point of view, dealing with physical and datalink activities. On the other hand, CANOpen is a protocol which lies in the OSI layer 7.

There is no need for intermediate layers in these kind of busses since all of them belong to the same network segment; neither the notion of session is available in CAN networks.



As can be seen in the image above, CANBus uses two wires for the communication bus and transceiver only need hook these two lines (and the ground). In some representations, as the above, you may see the bus both sides ended, this is usually done by a 120 Ohms resistor which is only mandatory when the bus exceeds a normal length.

For now, the fields, in a CANBus Frame, we are going to care about are identifier, which is 11 bit wide in the base version, and the data field holding as much as 8 bytes in each frame, the rest of the fields deal with synchronization of frames and error checking, you can find them in Wikipedia CAN Entry.



CANOpen is a protocol built on top of CAN, but can run in different link layers, which implements an object centric message system. The main entity in CANOpen is the Object Dictionary, which is a description of all the objects supported by an specific device, it doesn’t matter the format it is delivered in as long as both side of the communication are aware of it. The protocol is profile based defining each of them different objects that must be implemented by the device

Each Object has its own 16bit wide index and another 8bit wide address for referecing subdata fields.  As can be seen in the next table there range of these address which are mapped to specific functions described in different profiles e.g. CiA 301 (communication profile area):


Index Object
0000 Not Used
0001 – 001F Static Data Types (Boolean, Integer16, etc)
0020 – 003F Complex Data Types
0040 – 005F Manufacturer Specific Complex Data Types
0060 – 007F Device Profile Specific Static Data Types
0080 – 009F Device Profile Specific Complex Data Types
00A0 – 0FFF reserved
1000- 1FFF Communication Profile Area
2000 – 5FFF Manufacturer Specific Profile Area
6000 – 9FFF Standardised Device Profile Area
A000 – FFFF reserved

In order to simplify communication in CANOpen redefines the CAN identification scheme as follow and renaming it as COB-ID:


So with this new specification we have 4 bits to specify the function the message is requesting to perform and 7 bits spare for device’s ID which span from 1 to 127, being 0 forbidden.

Function Codes can be either pre-defined by the standard or custom, modified after the devices powers-up.

The tables below shows the configuration for the pre-defined connection set; the first for broadcast messages and the second one for peer-to-peer object messages:

Object Function Code COB-ID Communication Parameters at OD idx
NMT Module Control 0000 000h
SYNC 0001 080h 1005h, 1006h, 1007h
TIME STAMP 0010 100h 1012h, 1013h
Object Function Code COB-ID Communication Parameters at OD idx
EMERGENCY 0001 081h – 0FFh 1024h, 1015h
PD0 1 (transmit) 0011 181h – 1FFh 1800h
PD0 1 (receive) 0100 201h – 27Fh 1400h
PD0 2 (transmit) 0101 281h – 2FFh 1801h
PD0 2 (receive) 0110 301h – 37Fh 1401h
PD0 3 (transmit) 0111 381h – 3FFh 1802h
PD0 3 (receive) 1000 401h – 47Fh 1402h
PD0 4 (transmit) 1001 481h – 4FFh 1803h
PD0 4 (receive) 1010 501h – 57Fh 1403h
SDO (transmit/server) 1011 581h – 5FFh 1200h
PD0 4 (receive/client) 1100 601h – 67Fh 1200h
NMT Error Control 1110 701h – 77Fh 1016h, 1017h

Type of CANOpen Message


Administrative Messages:

  • This messages fall in the category of Master – Slave communication such as those dealing with initialization or  network configuration. As an example NMT is used to initialize, start/stop nodes, etc

Service Data messages (SDO):

  • This messages provide access to device’s objects using the Object Dictionary index and subindex and allows data transfer of any length.
  • Each message needs to be confirmed and each request / reply transports 8 bytes rendering this kind of service not suitable for RT data transfer.

Process Data Object (PDO):

  • Used to transfer RT data from one producer to several consumers and each message is limited up to 8 Bytes.
  • Each PDO is described by two objects, one for setting the COB-ID, transmission type, inhibit time and timer period and the other to map list of objects from the Object Dictionary mapped into the PDO.
  • The objects mapped to a PDO are configured using SDO messages.
  • There are to modes: SYNC (triggered by a SYNC object, ASYNC (triggered by a device event)
  • Inhibite time: Minimun time betweet 2 PDOs
  • Event Timer: Transmission Trigger

Predefined Messages:

  • SYNC: Used to synchronized operations across the network, when device receive a SYNC message the perform the expected action.
  • Time – Stamp: Common time frame reference
  • Emergency: Triggered by an error in a device
  • Node/Life Guarding: Monitor state of Devices, detects network errors, etc
  • Boot-up: By sending an NMT message the slave change from state Initialising to Preoperational