Table 2.1 Comparisons between CAN and FlexRay.
| CAN | FlexRay | |
| Bandwidth | 1 Mbps | 10 Mbps |
| Number of channels | 1 | 2 |
| Frame data length | 0~8 | 0~254 |
| Communication | Dynamic arbitration | TDMA |
| Complexity | Low | High |
| Composability | No | Yes |
| Flexibility | One topology | Many different topologies |
By designing network configurations ahead of time, network designers save significant cost and increase reliability of the network. For a TDMA network such as FlexRay to work correctly, all nodes must be configured correctly. The FlexRay standard is adaptable to many different types of networks and allows network designers to make tradeoffs between network update speeds, deterministic data volume, and dynamic data volume among other parameters. Every FlexRay network may be different, so each node must be programmed with correct network parameters before it can participate on the bus.
Table 2.1 provides a summary of comparisons between CAN and FlexRay [4]. For the rest of this chapter, we will focus on CAN as this is still the most popular protocol today and it is simple to use.
2.4 CANopen
CANopen is a communication protocol and device profile specification for embedded systems used in automation. In terms of the OSI model (shown in Figure 2.1), CANopen implements the layers above and including the network layer. The CANopen standard consists of an addressing scheme, several small communication protocols, and an application layer defined by a device profile [5].
The CANopen communication protocol has support for network management (NMT), device monitoring, and communication between nodes, including a simple transport layer for message segmentation and desegmentation. The lower level protocol implementing the data link and physical layers is usually CAN, although devices using some other means of communication (such as Ethernet Powerlink, EtherCAT) can also implement the CANopen device profile.
The basic CANopen device and communication profiles are given in the CiA 301 specification released by CAN in Automation. Profiles for more specialized devices are built on top of this basic profile, and are specified in numerous other standards released by CAN in Automation, such as CiA 401 for I/O modules and CiA 402 for motion control.
Every CANopen device has to implement certain standard features in its controlling software. A communication unit implements the protocols for messaging with the other nodes in the network. Starting and resetting the device is controlled via a state machine. It must contain the states Initialization, Pre-operational, Operational, and Stopped.
The transitions between states are made by issuing a NMT communication object to the device. The object dictionary is an array of variables with a 16-bit index. Additionally, each variable can have an 8-bit subindex. The variables can be used to configure the device and reflect its environment, i.e. contain measurement data.
The application part of the device actually performs the desired function of the device, after the state machine is set to the operational state. The application is configured by variables in the object dictionary and the data are sent and received through the communication layer.
2.4.1 Object Dictionary
CANopen devices must maintain an object dictionary, which is used for configuration and communication with the device. An entry in the object dictionary is defined by:
Index, the 16-bit address of the object in the dictionary.
Object name (Object Type/Size), a symbolic type of the object in the entry, such as an array, record, or simple variable.
Name, a string describing the entry.
Type, this gives the datatype of the variable (or the datatype of all variables of an array).
Attribute, which gives information on the access rights for this entry, this can be read/write, read-only, or write-only.
The Mandatory/Optional field (M/O) defines whether a device conforming to the device specification has to implement this object or not.
The basic data types for object dictionary values such as Boolean, integers, and floats are defined in the standard (their size in bits is optionally stored in the related type definition, index range 0x0001–0x001F), as well as composite data types such as strings, arrays, and records (defined in index range 0x0040–0x025F). The composite data types can be subindexed with an 8-bit index; the value in subindex 0 of an array or record indicates the number of elements in the data structure, and is of type UNSIGNED8.
2.4.2 Profile Family
CANopen defines a standardized application for distributed industrial automation systems based on CAN. The CANopen profile family is based on a “Communication Profile,” which specifies the basic communication mechanisms and on a standardized form for describing the functionality of devices.
The most important device types such as digital and analog I/O modules, drives, operating devices, sensors, or programmable controllers are described by so-called “Device Profiles.” In the device profiles the functionality, parameters, and data of standard devices of the corresponding types are specified. Based on the standardized profiles, devices of different manufacturers can be accessed via the bus in exactly the same manner. Therefore devices of different manufacturers are interoperable and exchangeable.
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.
2.4.3