Hybrid network: The bus and star topologies can be combined to form a hybrid topology. Future FlexRay networks will likely consist of hybrid networks to take advantage of the ease-of-use and cost advantages of the bus topology while applying the performance and reliability of star networks where needed in a vehicle.
2.3.2 The FlexRay Communication Protocol
The FlexRay communication protocol is a time-triggered protocol that provides options for deterministic data that arrive in a predictable time frame (down to the microsecond) as well as CAN-like dynamic event-driven data to handle a large variety of frames. FlexRay accomplishes this hybrid of core static frames and dynamic frames with a pre-set communication cycle that provides a predefined space for static and dynamic data. This space is configured with the network by the network designer.
While CAN nodes only need to know the correct baud rate to communicate, nodes on a FlexRay network must know how all the pieces of the network are configured in order to communicate. As with any multi-drop bus, only one node can electrically write data to the bus at a time. If two nodes were to write at the same time, you end up with contention on the bus and data become corrupt. There are a variety of schemes used to prevent contention on a bus. CAN, for example, used an arbitration scheme where nodes will yield to other nodes if they see a message with higher priority being sent on a bus. While flexible and easy to expand, this technique does not allow for very high data rates and cannot guarantee timely delivery of data.
FlexRay manages multiple nodes with a Time Division Multiple Access (TDMA) scheme. Every FlexRay node is synchronized to the same clock, and each node waits for its turn to write on the bus. Because the timing is consistent in a TDMA scheme, FlexRay is able to guarantee determinism or the consistency of data delivery to nodes on the network. This provides many advantages for systems that depend on up-to-date data between nodes. Embedded networks are different from PC-based networks in that they have a closed configuration and do not change once they are assembled in the production product. This eliminates the need for additional mechanisms to automatically discover and configure devices at run time.
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.1provides 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.
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.
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.
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.
Читать дальше