The CAN protocol (ISO 11898) has remained relatively unchanged since it was introduced in 1993 as CAN 2.0 A/B. In the last few years, CAN FD (for Flexible Data rate or “Fast Data” as we like to call it) was introduced and is now defined as ISO 11898-1. The CAN FD protocol is backward compatible. Any CAN FD device can understand CAN 2.0 frames (now known as “Classic CAN”). However, the opposite is not true. If a Classic CAN node encounters a CAN FD frame, it will destroy the packet with an error frame.
Classic CAN has been the de facto standard for in-vehicle communication for the automotive industry since the 90s. CAN has also been used as the lower-layer protocol for a number of other “higher-layer” protocols such as CANopen, J1939, DeviceNet and more. This has resulted in the CAN protocol being widely deployed in factory automation, heavy-duty vehicles and engines, and internal machine communication – such as elevators and medical equipment.
The automotive industry is the main driver behind the adaptation of CAN FD. The complexity of software in automobiles has increased over time, and the number of systems that communicate with each other via CAN bus has also increased. Between 1990 and 2000, the number of in-vehicle bus nodes went from about 10 nodes to more than 40 systems. This trend has continued into the 21st century, as in-vehicle communication demands have put further and further strain on vehicle design, causing an ever increasing number of CAN bus networks in the vehicle. Through the adaption of CAN FD, in-vehicle communication architectures will be able to accomplish more with less!
The basic idea of CAN FD is to speed up the bit rate during the “payload” part of a CAN frame. In this way up to 8 times more payload (64 bytes vs. 8 bytes) can be delivered in the same amount of time. So the beginning and end of the frame are transmitted at “Classic CAN” speeds, and the CAN transceivers just flip a switch and speed up for the payload part of the message. When you consider that the rest of the frame is at slower speeds, the overall increase in speed is about 6 times faster. Not all messages need 64 bytes of data of course, so the diagram below shows how a CAN FD message of 8 bits and 64 bytes compare to a Classic CAN frame of 8 bytes.
The question is why didn’t CAN FD just speed up the whole message? Why just the payload? The answer requires a slightly deeper understanding of the CAN protocol. A basic element of the CAN protocol is its arbitration process. When two nodes transmit at the same instant, their messages “collide” and they must both “back-off” and retransmit at different intervals according to priority. Another basic element of the protocol is that nodes on a bus must be reached within a “bit time” during this arbitration. The notion of a “bit time” has implications on the length of the bus – the actual cable, since electrical signals have a finite propagation speed. Therefore, a CAN bus running with 1 Mbit/s has a maximum length of 40 meters by rule of thumb. If CAN FD sped up the whole bus, the higher bit rates would shorten the bus cable to unsuitable lengths.
The automotive industry is readying itself to start initial implementation of CAN FD in its designs for 2016, with vehicles hitting the market with CAN FD hardware the following year. As this industry ramps up and more and more ECU’s (in-vehicle “Electronic Control Units) and sensors and actuators also adapt CAN FD, more companies with ties to automotive (suppliers, service companies, dealers, OEMs, etc.) will need CAN FD-capable interfaces. Luckily, Peak-System from Germany is one of the first companies to introduce a CAN-FD interface, (PCAN-USB-FD), and it has been fully tested to the standard. Additional hardware and software supporting CAN FD are on the way. Grid Connect has Peak’s CAN FD products in stock now – we are ready for the next big (fast) thing!
Discuss on X
Discuss on Reddit
Discuss on LinkedIn
