CMS derives from MMS (Manufacturing Mes-
sage Specification), which is an OSI application
layer protocol designed for the remote control
and monitoring of industrial devices.
2. NMT (Network ManagemenT):
offers services to support network management,
e.g. to initialize, start or stop nodes, detect node
failures; this service is implemented according
to a master-slave concept (there is one NMT
3. DBT (DistriBuTor):
offers a dynamic distribution of CAN identifiers
(officially called COB-ID, Communication Ob-
ject Identifier) to the nodes on the network; this
service is implemented according to a master-
slave concept (there is one DBT master).
4. LMT (Layer ManagemenT):
offers the ability to change layer parameters e.g.
change the NMT-address of a node,
or change bit-timing and baud-rate of the CAN-
CMS defines 8 priority levels in its messages,
each having 220 COB-IDs, occupying COB-IDs 1
to 1760; the remaining identifiers (0, 1761-2031)
are reserved for NMT, DBT and LMT. See Table 1.
In a CAN-network the lower the value of the
COB-ID, the higher the priority of the correspond-
ing message on the network is.
Note that this standard assumes CAN2.0A (CAN
Standard Message Frame) having an 11-bit identi-
fier, allowing a range of [0, 2047], but which -for
historical reasons- is limited to [0, 2031]. However
using CAN2.0B (CAN Extended Message Frame)
with 29-bit identifier doesn't change the picture: the
11-bits range in the table maps to the 11 most sig-
nificant bits of the 29-bits COB-ID and the COB-
ID ranges in the table will just become (much) lar-
CAN Application Layer (CAL)
0 NMT start/stop services
1 - 220 CMS objects priority 0
221 - 440 CMS objects priority 1
441 - 660 CMS objects priority 2
661 - 880 CMS objects priority 3
881 - 1100 CMS objects priority 4
1101 - 1320 CMS objects priority 5
1321 - 1540 CMS objects priority 6
1541 - 1760 CMS objects priority 7
1761 - 2015 NMT Node Guarding
2016 - 2031 NMT, LMT, DBT services
Table 1. COB-ID (11-bit CAN-identifier) map-
ping to CAL services and objects.
CAL provides all network management services
and message protocols, but it does not define the
contents of the CMS objects or the kind of objects
being communicated (it defines how, not what).
This is where CANopen enters the picture.
CANopen is built on top of CAL, using a subset of
CAL services and communication protocols; it pro-
vides an implementation of a distributed control
system using the services and protocols of CAL.
It does this in such a way that nodes can range
from simple to complex in their functionality with-
out compromising the interoperability between the
nodes in the network.
Central concept in CANopen is the Device Object
Dictionary (OD), a concept used in other fieldbus
systems as well (Profibus, Interbus-S).
Note that the Object Dictionary concept is not
part of CAL, it is an implementation aspect of
In the following sections we will first present the
Object Dictionary, and only then the CANopen
3.1 CANopen Object Dictionary
The CANopen Object Dictionary (OD) is an or-
dered grouping of objects; each object is addressed
using a 16-bit index. To allow individual elements
of structures of data to be accessed an 8-bit sub-
index has been defined as well. The general layout
of the CANopen OD is shown in Table 2.
Don't be confused by all the 'data types' located in
the OD at indices below 0FFF; they're there mainly