The Controller Area Network (CAN bus) is a message-based communication network standard that allows electronic control units (ECUs) to communicate within a vehicle without the use of dedicated analog signal wires. By utilizing multiplex wiring, CAN significantly reduces cost, complexity and weight of a design and allows new features to be implemented in firmware, allowing for over-the-air firmware updates and saving further on engineering design time.
Controller Area Network with Flexible Data Rate (CAN FD) is an extension to the Classic CAN protocol that was developed to meet the needs of modern vehicles wherever-increasing numbers of embedded electronics are transmitting ever-increasing amounts of control and diagnostic data. Because the original CAN specification has a maximum bandwidth limitation of 1 Mbps, data-dense activities like ECU flashing and advanced driver assistance systems (ADAS) applications were being impeded, forcing automotive manufacturers to add multiple CAN networks into newer vehicles. This required additional wiring, thus adding weight and complexity to the vehicle which decreased performance and fuel efficiency.
To solve this problem, CAN FD was developed to support flexible data rates (thus the name CAN with Flexible Data Rate) up to eight Mbps as well as to increase the data payload size from eight bytes up to 64 bytes. While there are other communication networks in the vehicle that support bandwidths over 1 Mbps, namely, automotive Ethernet and FlexRay, their physical layers are significantly different than that of CAN. Changing an entire vehicle communication network from CAN to one of these would be an extensive and costly undertaking for automotive manufacturers. CAN FD, on the other hand, has the same physical layer as high-speed CAN. This means that the only hardware change required for a CAN FD node is a controller that supports it and a CAN transceiver that allows the faster speeds. From a software perspective, while there are some key differences between Classic CAN frames and CAN FD frames, overall changes are minimal because the message format is so similar.
In 2015, the original CAN FD specification was updated to improve the failure detection capability by adding a four-bit Stuff-Bit Counter (SBC). This updated ISO standard is known as 11898-2:2015. Products compliant with the original standard are now known as a “non-ISO CAN FD” whereas products compliant with the updated standard are simply referred to as “CAN FD.” All references to CAN FD in this article refer to the updated protocol.
NXP's Irina Costachescu provides an overview of CAN FD standard:
CAN FD Frame Format
Let’s compare the similarities and differences between a Classic CAN frame and a CAN FD frame:
Figure 2: Standard CAN FD Frame
As shown in Figures 1 and 2 above, both Classic CAN and CAN FD begin with a Start of Frame (SOF) bit, followed by an Arbitration ID. The Arbitration ID can either be 11 bits long for a standard CAN (CAN 2.0A) frame or 29 bits long for an extended CAN (CAN 2.0B) frame.
After the Arbitration ID things start to look a little bit different. In Classic CAN, the Remote Transmission Request bit (RTR) determines whether the frame is a data frame or a remote frame. In CAN FD however, remote frames are not supported. Therefore, the Remote Request Substitution (RRS) bit used in CAN FD is always a dominant ‘0’.
Both Classic CAN and CAN FD have an Identifier (IDE) bit which Indicates whether the frame is in a base frame (11 bits) or extended frame (29 bits) format. After this is a Reserved bit, known as r0 in Classic CAN but updated to Flexible Data Format (FDF) with the release of the ISO 11898-1 standard in 2015. This bit differentiates the frame as either Classic CAN by returning a dominant ‘0’ bit or as CAN FD by returning a recessive ‘1’ bit.
Because the res, BRS and ESI bits appear before the DLC bit in a CAN FD frame, a Classic CAN controller would misinterpret this frame, resulting in an error frame. While CAN FD controllers can read Classic CAN frames the opposite is not true. If a Classic CAN controller encounters a CAN FD frame it will destroy the packet with an error frame.
In a CAN FD frame, the DLC follows these three new bits. The DLC is four bits wide in both Classic CAN and CAN FD, and both use the first eight of these values consistently. However, CAN FD uses the remaining seven bits to denote the number of data bytes used up to 64 bytes, as shown in Figure 3 below. The DLC is followed by the Data payload.
The Cyclic Redundancy Check (CRC) follows the data in both Classic CAN and CAN FD, but in CAN FD a four-bit Stuff-Bit Counter (SBC) is inserted ahead of the CRC. The purpose of the SBC is to reduce the number of single-bit errors not detected by the CRC calculation, thus providing better protection to the data content. The original version of CAN is now referred to as non-ISO CAN FD, whereas the updated version is simply called CAN FD. The CRC is limited to 15 bits in Classic CAN, but in CAN FD it is 17 bits for up to 16 data bytes, and 21 bits for 20-64 data bytes. Additionally, where Classic CAN may have anywhere from zero to three stuff-bits within the CRC, a CAN FD CRC contains four fixed stuff-bits. The addition of the SBC as well as the fixed bits within and longer length of the CRC make CAN FD frames longer than Classic CAN frames but provide better data protection for safety critical systems.
The Acknowledgement (ACK) bits come next in both Classic CAN and CAN FD frames, and if the CRC process is OK it will be indicated with a recessive ‘1.’ This is also where the potentially increased bit-rate in a CAN FD frame ends. Lastly, the End of Frame (EOF) is indicated with a recessive ‘1.’
Advantages of CAN FD
Whether or not it is sensible to make the switch to CAN FD depends on the application. If performance headroom or small payload size are nonissues, it may not be worthwhile to switch to CAN FD from an efficiency standpoint. For applications running up against the limitations of Classic CAN, however, CAN FD provides four main advantages:
- Increased data transfer rate – As previously mentioned, Classic CAN is capable of a maximum data bit-rate of 1 Mbps. CAN FD has a max data transfer rate of eight Mbps and can also dynamically switch to faster or slower bit-rates with larger or smaller frame sizes. This means CAN FD has higher bandwidth at lower latency, with better real-time performance.
- Support for larger payloads – Message payload size is increased to 64 bytes in CAN FD compared to eight bytes in a Classic CAN frame, leading to improved bus efficiency when sending larger amounts of data.
- Improved error detection – CAN FD boasts increased performance in the CRC algorithm over Classic CAN, thus lowering the risk of undetected errors.
- Security – As seen in the news in recent years, CAN bus hacking is a genuine threat with potentially catastrophic consequences. The increased bandwidth of CAN FD allows manufacturers to implement cryptography methods to secure data and authenticate devices on the bus.
In applications where you are running up against a performance ceiling with Classic CAN, making the move to CAN FD is probably merited. This is as simple as replacing the Classic CAN controllers with CAN FD controllers. It might also be worthwhile to future-proof a design by implementing CAN FD controllers in preparation for greater bandwidth needs even if the Classic CAN format will be used for the time being. It is worth noting, however, that for applications with less than eight bytes of data, Classic CAN is more efficient than CAN FD. This is due to the additional overhead bits in a CAN FD frame, making it longer than a Classic CAN frame even with less than eight bytes of data, which decreases the real-time performance. Of course, increasing the bit-speed with CAN FD offsets the larger frame size, but for data payloads below eight bytes, Classic CAN is still more efficient. As payloads increase toward 64 data bytes, the efficiency of CAN FD improves from 50% to nearly 90%.
CAN FD Applications
As more embedded electronics are added into automotive and industrial systems using CAN today, and more control and diagnostic data is desired from these systems, the need for faster data rates is driving these systems to CAN FD.
Currently, more and more of the automotive and industrial applications that have used Classic CAN in the past are moving to CAN FD to accommodate additional embedded electronics within their systems and the increased control and diagnostic data they produce. In particular, the markets and functions below have been instrumental in driving adoption of CAN FD because of the advantages it brings.
- Electric Vehicles – Powertrain systems are more complex and additional ECUs such as battery management are needed, requires higher bit rates.
- ECU Flashing – Making ECU updates via the OBD2 port can take hours, with the complexity of these updates only increasing. This process can be done four times faster with CAN FD.
- Robotics – Multi-axis robotic applications rely on time-synced behavior and require multiple, time-synced CAN frames to be sent by each controller. This data can be sent in a single frame with CAN FD.
- Advanced Driver Assistance Systems – These data-intensive systems put heavy pressure on the existing CAN bus within vehicles but are critical to improving automotive safety.
- Commercial Vehicles – Large vehicles like trucks and buses use long CAN buses and therefore rely on very slow bit-rates. CAN FD allows implementation of features such as ADAS into commercial vehicles.
- Secure Bus Communications – CAN is the most widely used bus in automotive and industrial applications, but it does not have the headroom to support appropriate security. CAN-FD allows manufacturers to protect devices from hackers who may want to take over ECUs in a system or to analyze or manipulate data traffic.
NXP's CAN FD solutions
As the world’s largest provider of automotive semiconductors, NXP provides multiple solutions with both Classic CAN and CAN FD including MCUs and processors with integrated CAN controllers, CAN transceivers, System Basis Chips and development tools and software that support all of these. To get started using CAN FD in your application, you can start from one of the examples included within our Model-Based Design Toolbox (MBDT), or within the MCUXpresso IDE or S32 Design Studio IDE .