Shaoshan Liu - Engineering Autonomous Vehicles and Robots

The key element of the CANopen standard is the description of the device functionality by means of an “Object Dictionary” (OD). The object dictionary is divided into two sections. The first section contains general device information such as device identification, manufacturer name, and so on, as well as communication parameters. The second section describes the specific device functionality. A 16-bit index and an 8-bit subindex identify an entry (“object”) in the object dictionary. The entries in the object dictionary provide the standardized access to the “Application Objects” of a device, such as input and output signals, device parameters, device functions, or network variables.

You can describe the functionality and characteristics of a CANopen device by means of an “Electronic Data Sheet” (EDS) using an ASCII format. An EDS must be understood as a kind of template for describing all the data and features of device as accessible from the network. The actual device settings are described by the so-called “Device Configuration File” (DCF). The EDS and DCF can be provided in the form of a data file, which can be downloaded from the Internet or stored inside the device.

Similar to other field bus systems, CANopen distinguishes two basic data transmission mechanisms: the access to entries of the object dictionary through “Service Data Objects” (SDOs) The exchange of process data through “Process Data Objects” (PDOs). PDOs are transmitted according to the producer–consumer principle in the form of broadcast messages and can be event-triggered, cyclically transmitted, or requested by a node without any additional protocol overhead. A PDO can be used for the transmission of a maximum of 8 data bytes.

In connection with a synchronization message (“Synchronous PDO”), the transmission as well as the acceptance of PDOs can be synchronized across the network. The mapping of application objects into the data field of a PDO is configurable through a data structure called “PDO Mapping” which is stored in the object dictionary. This allows the dynamic configuration of a device according to the specific requirements of an application.

The transmission of data via an SDO channel is performed in the form of a client–server relationship between two nodes. The addressing of an object dictionary entry is accomplished by providing the index and the subindex of the entry. Transmitted messages can be of very large length. The transmission of SDO messages of more than 8 bytes involves an additional fragmentation protocol overhead. Standardized event-triggered “Emergency Messages” of high priority are reserved to report device malfunctions. A common system time can be provided through a system time message.

NMT functions such as controlling and monitoring the communication status of the nodes are accomplished by a NMT facility. This is organized according to a logical master–slave relationship. Two mechanisms for node monitoring (“node-guarding” and “heartbeat-messaging”) are provided alternatively. The assignment of CAN message identifiers to PDOs and SDOs is possible by direct modifications of identifiers in the data structure of the object dictionary or, for simple system structures, through the use of predefined identifiers. Besides device profiles, a variety of application specific profiles developed by several specific interest groups are currently available and a wide variety of manufacturers support CANopen by means of CANopen-based devices, tools for configuration, and testing as well as certified CANopen protocol stacks.

CAN bus, the data link layer of CANopen, can only transmit short packages consisting of an 11-bit identifier, a remote transmission request (RTR) bit and 0–8 bytes of data. The CANopen standard divides the 11-bit CAN frame identifier into a 4-bit function code and 7-bit CANopen node ID. This limits the number of devices in a CANopen network to 127 (0 being reserved for broadcast). An extension to the CAN bus standard (CAN 2.0 B) allows extended frame identifiers of 29 bits but in practice CANopen networks big enough to need the extended identifier range are rarely seen. In CANopen the 11-bit identifier of a CAN-frame is known as a communication object identifier, or COB-ID. In the case of a transmission collision, the bus arbitration used in the CAN bus allows the frame with the smallest identifier to be transmitted first and without a delay. Using a low code number for time critical functions ensures the lowest possible delay.

Different kinds of communication models are used in the messaging between CANopen nodes. In a master–slave relationship, one CANopen node is designated as the master, which sends or requests data from the slaves. The NMT protocol is an example of a master–slave communication model. A client–server relationship is implemented in the SDO protocol, where the SDO client sends data (the object dictionary index and subindex) to an SDO server, which replies with one or more SDO packages containing the requested data (the contents of the object dictionary at the given index). A producer–consumer model is used in the Heartbeat and Node Guarding protocols. In the push model of producer–consumer, the producer sends data to the consumer without a specific request, whereas in the pull model, the consumer has to request the data from the producer.

CANopenNode is free and open source CANopen Stack is written in ANSI C in an object-oriented way [6]. It runs on different microcontrollers, as a standalone application, or with a real-time operating system. Stack includes master functionalities.

CANopenNode implements the following CANopen features:

NMT slave to start, stop, reset device. Simple NMT master.

Heartbeat producer–consumer error control.

PDO linking and dynamic mapping for fast exchange of process variables.

SDO expedited, segmented and block transfer for service access to all parameters.

SDO master.

Emergency message.

Sync producer–consumer.

Non-volatile storage.

CANopenNode itself does not have complete working code for any microcontroller. It is only the library with the stack and drivers for different microcontrollers. CANopenNode contains sample codes, which should compile on any system with a template driver, which actually does not access CAN hardware. CANopenNode should be used as a git submodule included in a project with specific hardware and specific application.

Figure 2.4 Flowchart of a typical CANopenNode implementation.

Figure 2.4shows the flowchart of a typical CANopenNode implementation: when the program starts, it calls CANopen init, and spawns multiple threads. The CAN receive thread listens for any CAN messages and provides fast responses by processing messages and copying data to target CANopen objects. The timer interval thread is a real-time thread that wakes up every millisecond to deal with inputs to and outputs from the object dictionary. The mainline thread handles the processing of time-consuming tasks by calling the corresponding application code.

1 1 National Instruments (2017). Controller Area Network (CAN) Tutorial. http://download.ni.com/pub/devzone/tut/can_tutorial.pdf(accessed 1 October 2018).

2 2 Contemporary Controls (2017). CAN Tutorial. https://www.ccontrols.com/pdf/CANtutorial.pdf(accessed 1 October 2018).

3 3 National Instruments (2017). FlexRay Automotive Communication Bus Overview. http://www.ni.com/white-paper/3352/en(accessed 1 October 2018).