CANopen Basics - Network Management
CANopen network management (NMT)
In addition to providing services and protocols for the transmission of process data and the configuration
of devices, the operation of a system distributed over a network requires functions for the command control of the
communication state of the individual network nodes. As data transmission by CANopen devices is in many cases
event-controlled, continual monitoring of the communication ability of the network nodes is also required.
CANopen provides so-called "network management" services and protocols for these tasks, namely
- control of the communication state of network nodes and
- node monitoring.
Status of a CANopen network node and state control via NMT messages
CANopen describes the communication state of a network node in a state diagram. By sending specific CAN messages
(NMT messages), the network management master can control the communication state of the other nodes (the network
management slaves) of a CANopen network, i.e. it can change the state of all nodes or of an individual node by a
NMT messages are transmitted with the highest priority message identifier (CAN-ID 0). The data field consists of
only two bytes: the required target state is coded in the first data byte, the second data byte specifies the number
of the node whose communication state is to be altered. All nodes of a network are jointly addressed with the virtual
node-ID 0; in this way, for example, all nodes can be set to "Operational" state at the same time for the sake of a
simultaneous start of operation.
States and changes of state
In order to enable even a partial reset of a certain node, this state is subdivided into three sub-states:
"Reset-Application", "Reset-Communication" and "Initializing".
After an HW-Reset or Power-On, a node is in the "Initializing" state. After completion of the basic
node initialization (e.g. host controller, CAN controller, application software, etc.), the node transmits
the so-called "boot-up message" and switches itself to the "Pre-operational" state.
In the sub-state "Reset-Application", the parameters of the manufacturer-specific and of the standard device
profile are reset to their Power-On values (corresponds to the last values saved). Then the node changes
to the sub-state "Reset-Communication". In the sub-state "Reset-Communication", the parameters of the
communication profile are reset to the Power-On values. Then the node state switches to "Initializing".
This state is primarily used for the configuration of CANopen devices. Therefore exchange of process
data (via PDOs) is not possible in this state. The entries of the device object dictionaries can be
accessed via "service data objects" (SDOs). By transmitting an SDO message, the object dictionary of a
certain device can be modified, e.g. with a configuration tool.
In addition to communication via SDO messages, emergency, synchronization, time stamp and of course
NMT control messages can also be transmitted or received in the Pre-operational state. By transmitting a
"Start-Remote-Node", a node switches to the "Operational" state.
In this state, the transmission of of process data via so-called "process data objects" (PDOs) is possible.
Except for node guarding or heartbeat messages, a node cannot transmit or receive any other messages in this state.
CANopen Device Monitoring using node guarding and heartbeat mechanisms
To ensure operability of network nodes, CANopen provides two alternatives:
- Cyclic querying of the node state by a higher order instance, the so-called "NMT-Master" ("node guarding" principle) or
- Automatic transmission of a "heartbeat message" by the network nodes ("heartbeat" principle).
One CAN-ID per node is required to monitor the device communication state. Low priority message identifiers
with a value of 1792 + node-ID are reserved for this.
With node guarding, the NMT-master requests the other nodes in the network (referred to accordingly as NMT-slaves)
with a CAN remote frame one after the other at defined intervals ("guard time") to transmit a data telegram with
its current communication state (stopped, operational, pre-operational) together with a toggle-bit. If a node does
not respond to the request of the NMT-master within a certain time (node life time), this is assessed as a failure
of the node and indicated to the host controller of the NMT-master as a "node-guarding event". On the other hand,
the NMT-slaves also monitor whether they have received a request from the NMT-master within their "life time".
If such a request was absent for longer than the so-called "life time factor" of a node, the NMT-slave assumes
that the NMT-master itself has failed and indicates this event as "Life guarding event" to its host controller.
With node monitoring according to the heartbeat principle, a node automatically transmits its communication
state at regular intervals as evidence of its communication ability. The interval between two heartbeat messages
("heartbeat interval") of a so-called heartbeat producer is configured via the object directory entry . A
value of 0 disables the heartbeat mechanism. The so-called "heartbeat consumer time" of up to 127 network nodes
is given in the OD entry . This time interval describes the maximum time periode for the arrival of a
heartbeat message at a monitoring node.
Nowadays, node guarding is no longer used. This might be mainly tribute to the higher bus load (due to
2 CAN messages per monitoring interval) but also to the undesirable centralisation of the crucial node healthy
survey at the NMT-master.