Understanding CAN FD (Flexible Data-Rate) vs. CAN

Overview

With the constantly growing amount of electronics and data being communicated in modern-day vehicles, the CAN with Flexible Data-Rate (CAN FD) protocol was created to meet industry and consumer demands. As a result, engineers in the automotive industry need to understand the protocol on a deeper level in order to be able to take advantage of its capabilities. This whitepaper will cover the motivation for the new protocol, the key technical specifications that make it different from traditional CAN, and introduce NI tools that can be used to test and simulate CAN FD devices.

Contents

Motivation for CAN FD vs. CAN

The Controller Area Network (CAN) protocol has been around since the 1980s and has become the most widely used in-vehicle network for ECU and sensor communication.   However, traditional CAN bandwidth is limited to 1 Mbit/s or less and a maximum payload size of 8 bytes per frame. CAN-FD improves on both these specifications with a higher bandwidth—typically 2 or 5 Mbit/s—and a top payload size of 64 bytes per frame. With growing consumer, safety, and legislative demands on cars, the number of embedded electronics transmitting data is constantly rising and the amount of data being used for control and diagnostic data is rising even faster.  This has created the need to be able to transmit more data inside the vehicle to achieve the functionality required for vehicles today.  But just as with everything in the car, the cost of being able to do this is critical and must be minimized in order for the industry to adopt it on a large scale.  The CAN FD protocol achieves this by enabling two key industry requirements:

Increased Automotive Electronics Communication Bandwidth

The original CAN specification defined in the ISO 11898 standard limits the network communication to a maximum bandwidth of 1 Mbit/s.  This limitation causes automotive suppliers and manufacturers wanting to continue to use the CAN protocol to design additional CAN networks into the vehicle in order to transmit the necessary data.  However, more networks in a car require significant additional wiring, which adds to the weight of the vehicle and decreases vehicle performance and fuel efficiency. 

CAN FD solves the bandwidth limitation problem by allowing bit-rates higher than 1 Mbit/s while also increasing the support of payloads in a CAN FD message above the previous maximum of 8 bytes.  Many automotive companies are still looking at the bit-rates they will use in the car, but some of the most common ones are 2 and 5 Mbit/s while others are looking at using up to 8 Mbit/s for key applications like ECU flashing and transmitting long messages.  CAN FD formatted frames significantly increase the payload support by allowing up to 64 bytes in a single message.

 

Figure 1. A faster bit-rate for CAN FD payloads allows for more data to fit into a single message.

Minimal Upgrade and Migration Costs

Outside of CAN, there are other in-vehicle networks that have higher communication bandwidths than 1 Mbit/s.  However, these networks, like FlexRay and automotive Ethernet, are significantly different from the CAN physical layer, which means that making a change to support them instead of CAN is very expensive for the suppliers and OEMs. 

CAN FD is also ideal for this problem because the physical layer is the same as high-speed CAN.  The only difference in the hardware is to use a new protocol controller with a qualified transceiver that allows the faster speeds.  Also, the software changes are minimal since the message format is very similar.  In fact, there are no software changes needed when using CAN FD messages at speeds up to 1 Mbit/s and 8 byte payloads.

CAN FD Message Format

There are many similarities between a typical CAN message format and the format of a CAN FD message, but there are several key differences that need to be taken into account.  The important additions and CAN FD message format specifications are outlined below:

 

Figure 2. The CAN FD Message Format has specific fields for larger payloads and faster bit-rates.

  • Extended Data Length (EDL): the reserved bit after the IDE or after the RTR bit in a standard CAN frame that is transmitted recessive.
  • r1, r0: r1 is reserved for future protocol expansion and r0 is used for resynchronization before the optional bit-rate switch.  Both bits are transmitted dominant.
  • Bit Rate Switch (BRS): A dominant transmission means the bit-rate in the data phase is the same as the arbitration phase while a recessive transmission signifies a faster bit-rate for the data phase.
  • Error State Indicator (ESI): a dominant transmission for error active and recessive transmission for error passive.
  • Data Length Code (DLC): DLC values ranging from 1001 to 1111 are used to specify the data lengths of 12, 16, 20, 24, 32, 48, and 64 bytes.
  • Cyclic Redundancy Check (CRC): The length of the CRC depends upon the length of the DLC and EDL. The CRC is 15-bits for CAN messages and either 17 or 21-bits for CAN FD.

 

NI Tools for CAN FD Communication

The NI-XNET family of CAN interfaces are designed to be high-performance modules that are easily adaptable to new standards and protocols.  Since the CAN FD physical layer is very similar to that of high-speed CAN, all NI-XNET CAN interfaces that support high-speed CAN communication also support CAN FD with bit rates up to 8 Mbit/s. 

The list of NI-XNET interfaces that support CAN FD communication is below:

  • NI-9862
  • USB-8502
  • NI PXI-8513/2
  • NI PXI-8513
  • NI PXI-8512/2
  • NI PXI-8512
  • NI PCI-8513/2
  • NI PCI-8513
  • NI PCI-8512/2
  • NI PCI-8512
  • cDAQ-9134 and cDAQ-9135 with TRC-8542 or TRC-8543
  • PCIe-8510 with TRC-8542 or TRC-8543
  • PXIe-8510 with TRC-8542 or TRC-8543
  • NI-9860 with TRC-8542 or TRC-8543

These interfaces combined with the powerful and intuitive NI-XNET API equip engineers with flexible tools for CAN FD testing and simulation throughout the entire development cycle.