[PEAK and the CAN FD standard - Read more about supported products below]

CAN FD Technology Introduction

Why CAN FD?

The growing demands in the number of nodes, transfer rates and cycle times lead to bottlenecks that the limitations of classic CAN (8 data bytes and 1 Mbit/s data rate) cannot fulfill: The data rate that depends on the network expansion and the short data length for service and analogue data play a particular role here.

In daily use, these limitations are often circumvented by means of compromises: The division of the system into different network segments in various applications – or even into parallel networks – means that the existing technology is constantly being exhausted, which has often led to solutions that are complex and expensive in terms of configuration, setup and maintenance. In principle, a switch to high-performance industrial Ethernet technologies would be possible. The increased level of investment usually necessary and the change in the data structures and mode of thinking for the configuration, in particular for time-controlled systems, often represent a considerable challenge in extensive networks. In addition, a switch in tools for development, commissioning and service is necessary, which often deters many users from a complete conversion.
At the same time, there is a desire to continue to use existing know-how in a useful manner.

This is where CAN FD plays a role: CAN FD (CAN with flexible data rate) is an extended version of the well-known "classic" CAN introduced by Bosch in 2012 and that significantly extends the usable data rate and usable data length. On the other hand, tried-and-tested CAN concepts have been retained: arbitration based on message IDs, event-driven dispatch of messages and acknowledgement of messages received by means of the acknowledgement bit.

Improved data rate

Message acknowledgement by receivers, which is used in classic CAN, offers a wide range of advantages by means of confirming the success of the transmission within the transmitted message – potential transmission errors are quickly detected and the data can be re-transmitted extremely quickly.
Arbitration of the messages based on the CAN identifier also offers advantages for control applications by avoiding collisions during data transmission and providing short latency times for high-priority messages even at higher busloads.

The disadvantage of the methods used is that at sampling time the same bus level must exist at all nodes to avoid faults. Accordingly, a bit interval must make sufficient signal propagation time available between the two most remote nodes in a network, including their bus activation. The bit interval and consequently also the data rate is thus directly dependent on the network extension; at an expansion of 40 m up to 1 Mbit/s is possible, but at 250 m extension this drops to as low as 250 kBit/s.

To significantly increase the data rate without changing the existing communications technology, CAN FD works with two different bit rates. The "arbitration rate" for the control commands (including arbitration, message type, end detection and acknowledgement) is dependent on the propagation speed and thereby on the network extension. By contrast, a second "data bit rate" is optionally also used – for the data content and data security. At this point in time, only the message transmitter occupies the bus, which means that direct feedback within the bit time is unnecessary. The maximum achievable data rate is therefore only dependent on the transmission characteristic of the transmission medium, and not the signal propagation. CAN FD networks currently enable productive use with 8 MBit/s, whereby the CAN FD standard permits up to 15 Mbit/s. This bit rate has also been successfully used in various test systems.

CAN FD introduces two separate bit rates: The Arbitration Bit Rate governs arbitration, control fields, and acknowledgement. Its speed depends on the physical length of the network. The Data Bit Rate applies to the data field and CRC. Since only the transmitter occupies the bus during this phase, the speed can be increased independently of the network length.

The two data rates are set independently of one another in the CAN FD controller using two-bit timing registers. Switching between the two data rates is performed using two control bits in the protocol. The first bit reserved up till now is used as the "Extended Data Length" bit (EDL), and defines a CAN FD message due to its recessive level. The actual bit rate switch is performed by a newly added bit, the "Bit Rate Switch" bit (BRS), in which a switch to the higher bit rate is made at sampling time. Switching back is performed at the time that the CRC restriction bit is sampled.

Extended user data

The control data is still transmitted using the well-known lower bit rates, thereby limiting the achievable data rates. By increasing the user data area to up to 64 bytes, more data can be sent in fast transfer mode, thereby effectively increasing the data rate.

Classic CAN provides only 8 data bytes, which is no longer sufficient for many data applications, e.g. for transmitting high-precision analog values or for controlling a multi-axle robot with its diverse encoding values and drive commands. To this, service data must also be added, which up to now has significantly reduced the effectiveness due to the transport protocols required for transmission of more than 8 bytes.

CAN FD now provides the option to use up to 64 data bytes. In so doing, larger data blocks can be transmitted in a single message – particularly in the case of process data, more complex devices can now be completely controlled using only a single process message. For service data, the necessity for transport protocols is reduced, as a single CAN FD message is often only required for configuration data and similar.

To prevent extending the control data unnecessarily, CAN FD also uses only 4 bits for the data length code – the values 0 to 8 are taken directly from classic CAN. The values that were up to now undefined (9 to 15, i.e. 1001 to 1111) are used for the new, extended data lengths: besides 0 to 8 bytes, 12, 16, 20, 24, 32, 48 and 64 bytes are now also available for the user data. Data lengths that differ from these are not possible, that is, unused areas must be padded with "filler values".

Besides the fast transmission of the data area, the effectively usable data rate can be significantly increased using CAN FD, and the cycle time can be considerably reduced. In this manner, a CAN FD network with 500 kBit arbitration, 4 MBit data transmission and 64 data bytes can achieve an effective data rate of over 5 MBit/s.

The CAN FD frame with all elements and meanings

Real-time capability

The combining of multiple independent data packets into a single message means that data administration is made considerably simpler, as the individual messages no longer need to be synchronized with one another at great cost. The fast transmission of larger data packets by comparison to classic CAN enables transfer of 8 times the data volume (64 bytes) in roughly the same time that would be required for a classic 8-byte CAN message. In this way, high-priority messages can be transmitted much more quickly and the real-time capability improved.

Data security

Data security is an important topic: Despite the increased data packet size in comparison to classic CAN, CAN FD fulfills the same requirements in respect of data security. This is achieved by using longer CRC check keys with adapted algorithms, for example. Depending on the number of data bytes transmitted, one of three different CRC algorithms is used: the previous CRC formula for messages with up to 8 data bytes, as well as two enhanced algorithms with up to 16 data bytes or more than 16 data bytes for messages. The algorithm to be used by the CAN controller is determined by the data length code.

For improved data security, additional suggestions have been implemented. As a result, the CRC in CAN FD messages always starts with a stuff bit; after another 5 bits an additional stuff bit is included – contrary to the CAN stuff bit rule, this is independent of the bit values of the previous bits. Each stuff bit has the complementary value of the previous bit.

Backward compatibility

One disadvantage of switching from CAN to faster communications systems is the frequent requirement for a complete conversion: All CAN participants must be adapted to the new system, e.g. EtherCAT. Alternatively, the machine controller can be extended to use multiple heterogeneous networks. Both procedures offer advantages and disadvantages. Using CAN FD, an additional "gentler" option is now also available: As CAN FD controllers can be used as classic CAN nodes as well, all network nodes can be gradually replaced by CAN FD-capable devices. As soon as the entire network is CAN FD-capable, the advantages of CAN FD can be used to the fullest extent. This is of particular interest for special purpose machinery, as network participants that cannot be replaced by freely available nodes are often also used here – in particular, customer-specific devices or internally developed devices.

PEAK and the CAN FD standard

With the release of various hardware and software products, PEAK-System is a pioneer in the introduction of the CAN FD standard.

With CAN FD (Flexible Data rate) the robust and long- lasting CAN specification has been extended with properties which are primarily designed for larger amounts of data. Higher bit rates up to 12 Mbit/s for the data of the CAN frames and the use of up to 64 data bytes in a single CAN frame are the main criteria.

CAN FD is downward-compatible to the CAN 2.0 A/B standard, thus CAN FD nodes can be used in existing CAN networks. However, in this case the CAN FD extensions are not applicable.

Since the first implementations of CAN FD, the protocol has been improved and is now included in the standard ISO 11898-1. The revised CAN FD standard is not compatible with the original protocol. PEAK-System takes this into account by supporting both protocol versions with their CAN FD interfaces. If required, the user can switch to the CAN FD protocol used in the environment by software („Non-ISO“ and „ISO“).