How CAN FD improves CAN real-time performance

Hi, I am Kent Lennartsson. I am the research manager at Kvaser. In the previous part we showed why we need CAN and CAN-FD to get good real-time performance. In this part, it is shown how CAN-FD makes it possible to increase performance in your CAN-system. To show this, will I use some animations.

CAN is designed in such way that no bit is corrupted during a collision.  By prioritization it is possible to have 100% bus-load, without any delays caused by collision. With CAN-FD it is possible to increase the bit-rate from 1 up to 10 Mbit/s, still without any delays caused by collision.

The good real time performance in CAN doesn’t come for free. In order to evaluate CAN frame priority, every bit needs to cover all connected units. The bit is spread over the cable by the speed of light. If the distance between units is less than 40 meters, it is possible to use up to 1 Mbit/s. If a longer cable is used, every bit needs more time to be distributed and the bit rate must be lowered to 250 or 500 kBits/s. CAN is very responsive when controlling a car or a machine, but doesn’t perform so well for sending video or large data files. However, with CAN FD it is possible to retain CAN’s good real-time behavior with much higher data throughput.

Let us see, how CAN-FD is implemented in the CAN-frame. The first bit in the CAN-frame is the Start Of Frame, this is a single bit, that synchronizes all units connected to the CAN-bus and start the priority process. After this bit comes the priority section, where several units could be sending in parallel during the arbitration process. The CAN frame with the highest priority wins access to the bus line. The following part is the data part that will be sent by the single winner of the arbitration. After the data section, there is an end of frame, that synchronizes the units, in preparation for the next CAN frame. This ensures that it is possible to start a new CAN frame without any delay in-between.

CAN’s limited bit-rate ensures that arbitration works successfully in the first part of the CAN-frame. The data section after arbitration is sent by one single unit. When there is just one sender, it is possible to increase the bit-rate. This possibility available in CAN is utilized by the CAN-FD standard. The beginning and the end of the CAN frame will keep the arbitration CAN bit-rate to secure the real time performance. This is the main difference between CAN and CAN FD.  CAN FD increases the bit-rate by switching to a shorter bit time after the arbitration process and returns to the arbitration bit time after the CRC Delimiter.

This CAN frame has one single byte of data. However, in CAN, it is possible to have up to 8 bytes of data. When data bytes, together with Data Length Code and CRC-bits, all framed in blue, are sent at a higher bit-rate, will it reduce the CAN frame length in time. CAN limit the number of bytes in a CAN frame to 8 Bytes. In CAN FD, it is possible to have up to 64 byte of data. By increasing the bit-rate on such a large frame, it’s possible to reduce the frame length considerably.

The combination of CAN prioritized access to the communication and the higher bit-rate in CAN-FD makes it possible to combine advanced real-time performance and high data throughput. Your system can be optimized by using CAN FD technology in two different ways. Either, CAN-FD makes CAN-frames shorter in time, to decrease the delay and increase real-time performance. Or put more data bytes in the CAN-frames to decrease the overhead. Of course, it is possible to combine those two features by putting more data in the CAN FD frames and still make them shorter by increasing the bit-rate.

Welcome to CAN FD. CAN-FD will bring better real time performance and higher data throughput in your existing CAN-system. With CAN-FD, you will get this high performance with minor changes to your software, hardware and the tools already in use today. Good luck with your CAN-FD projects. If you need more information go to our homepage, kvaser.com.

Hope to see you back soon.

Hi, I am Kent Lennartsson. I’m the research manager at Kvaser AB. I and Lars-Berno founded Kvaser in 1985. Our first CANbird was launched in 1989 based on the Phillips 82C200 and Intel 82856 CAN controller. This is a short overview of the CAN technology and the functionality of CAN FD important for the future CAN applications.

We start with a quick history of CAN. The CAN protocol was first defined in mid 1980 by a team at Bosch led by Owe Kiencke. CAN was presented before a broader public in 1987 as the future data communication standard to be used by the automotive industry. The CAN protocol has some nice features optimized for real-time control systems. By 1989, very soon after the first publication, Dornier, a manufacturer of weaving looms, was using CAN in the airjet weaving machines. The first automotive application of CAN was in the Mercedes S Class 1993.

Here is a simplified animation of a car. The driver expects a direct response to any input, like controlling the headlight, is not good enough to be responsive in 99.99% of the cases. The driver expects the car to respond accurately each and every time over the car’s entire lifetime. A communication delay would be as bad as having air in the brake lines. In this simplified view of the car there are four control units. One at the brake pedal, sensing how hard the driver compresses the pedal, one at the front wheel braking, one for rear wheel braking, and one for displaying the braking condition to cars behind.

All control units are connected together by the data communication bus line. By 1973, Ethernet was already running at 3MB/s. Today Ethernet supports speeds of 10, 100 and even 1000MB/s. There is a certain probability that two units will start sending an Ethernet frame at the same time. This will result in a collision and the sending process will stop. All units wait a random delay time before they restart sending. If after such delay collisions still occur, the random delay time is increased until one unit starts sending before all other units. Ethernet is very efficient as long as there is no collision. If the busload is high, the transfer delay can increase significantly due to collision. There are solution where additional rules can be added on top of the Ethernet protocol to reduce or even remove this problem. With CAN collision is solved without any delay. With CAN every package has a priority level. There can be up to 53 million different priority levels in CAN. In this example we only show four levels. As soon as there is no traffic on the CAN bus, any unit can send package. At this point CAN function is same as Ethernet. The difference occurs when there is a collision. In CAN the collision can be resolved in real time because the highest priority package will be sent first. There is no priority between the different units and a unit can send packages with different priorities. CAN is designed in such a way that no bit is corrected during a collision. This makes it possible to have 100% busload without causing any delays. The cost for this nice feature is a bit-rate below 1MB/s. With CAN FD it is possible to increase the bit-rate from 1 to 10MB/s still without any delay caused by the collisions. Here we have one of our products supporting CAN FD. In this case it’s the PCI-Express board with four CAN FD controllers. All four in these Atera FPGA.

Such a board is installed in this computer here running a CAN FD application and the bus from that application is connected to the oscilloscope here where we can see a classic CAN frame with 8 byte of data. If we switch to CAN FD we will see that the length of the message is decreased to 20% of the classical CAN frame. CAN FD also support 64 byte of data and you can see here how we increase the number of byte from 8 to 64 where the CAN FD frame become longer. Still, the CAN FD frame is only 50% of the classical CAN frame with 8 byte of data.

In coming with use we will describe how CAN FD provide this higher bit-rate and more data into the CAN frame. Good luck now with your CAN FD projects and if you need more information go to our homepage. Hope to see you soon.