CAN FD

The management

The main reason to move from Classical CAN to CAN FD is to achieve an increase performance with incremental steps. By simply replacing the CAN controllers, it is possible to use CAN FD and you should expect the same EMC and environment performance. If for any reason the CAN FD communication proves problematic, it is easy to switch back to Classical CAN until a solution has been found.

If you have a working CAN solution, there is no strategic reason for making an immediate switch to CAN FD. However, for future system developments, CAN FD offers the opportunity for more functionality, which in turn will require more software, more communication and more data to be sent through the system. For this reason, a good idea would be to implement CAN FD controllers in new products, even if your intention is to keep using the Classical CAN format. This will ensure your products are ready to cope with the higher bandwidth of CAN FD.

A key challenge for CAN FD is that all products with Classical CAN controllers need to be replaced with CAN FD controllers before CAN FD frames can be used on the CAN bus. A solution to this is to use two CAN buses, one with Classical CAN frames and one with CAN FD frames, with a router or filter between the two. Kvaser has described a filter that can be placed between the CAN driver and the CAN controller or between two CAN buses that prevents CAN FD frames from reaching the Classical CAN controllers.

The CAN software application engineer.

The only difference between CAN and CAN FD is the ability to send more than 8 bytes of data. In CAN FD is it possible to send up to 64 byte of data, but it is limited to a few different lengths as shown in table 1.

Table 1 DLC to number of data converter

In many cases it is possible to write much simpler code if the data structures are larger than 8 bytes because all data can be sent in just one package, instead of being fragmented into several messages.

Note that if your data structures do not exactly match the data bytes in the CAN frame, it is necessary to fill the structure with dummy data. If the data structure is not filled with dummy data, random data stored in the CAN buffer will be sent in the CAN frame. One suggestion is to fill up the unused data bytes with 0xCC or 0x55, because this produces plenty of edges that in turn help the receivers to stay in sync with the bits in the CAN frame.

You will get some resistance from the real-time engineers when requesting CAN frames above 8 bytes.

CAN FD provides a higher data bandwidth, but without modification of the cables, connectors, filters and CAN drivers, you should not expect more than 2 to 4 times an increase in bandwidth. To limit the time a CAN frame can occupy the CAN bus you could expect some restriction for using CAN frames above 16 bytes.  If there is low real-time demand, it is possible to use any data length without any restrictions. This is the typical case when you downloading new software under service.

CAN FD could change your system performance dramatically both for better and for worse.

CAN FD will change the real time performance in three ways:

1. CAN FD allows data to be sent at a higher bit-rate and by that reduce the time for the data part in the CAN frame. This makes all the CAN frames much shorter and thus, lowers the latency.
2. It is possible to increase the data load above 8 byte, up to 64 byte. In this way, CAN frames are produced that are almost 8 times longer than Classical CAN frames. The downside is that the increased data load causes longer delays between CAN frames, though this can be compensated for by using a higher bit-rate.
3. There are more overhead bits in CAN FD so that even with less than 8 bytes of data, CAN FD frames are some longer in time than Classical CAN frames.

To keep real-time performance unchanged, it is necessary to tightly control package length. Data packages longer than 8 byte can significantly increase latency (up to 8 times per CAN frame when using 64 byte CAN frames). On the other hand, it is possible to lower latency by increasing the bit-rate to make all CAN frames much shorter. By increasing bit-rate, even a 64 byte CAN FD-frame can be made shorter than a Classical-CAN-frame with 8 byte. However, this increase of bit-rate doesn’t come for free because the degree to which it is possible to increase the bit-rate depends on the design of the physical layer.

Your department will be squeezed between software engineers demanding more data in the CAN frames without increasing the latency, and the electrical engineers trying to make the physical layer run at the higher bit-rate. To simplify the software application, in most cases it is easier to send 64 byte packages, to reduce the numbers of interrupts and data handlings. This will demand rescheduling of the CAN frames or increasing the bit rate to reduce the length of the CAN FD frame.

In most cases it won’t be a problem to double the bit-rate. When increasing bit-rate by more than that, it will be necessary to test the physical layer to ensure that you still have the same EMC performance.

The CAN driver software engineer.

There are three design challenges that you need to consider carefully:

1. The increase of data bytes from 8 to 64 byte.
2. Fitting the data-structures within the restricted number of data-length supported in CAN FD.
3. Handling two different bit-rates.

Table 2 DLC to number of data converter

In CAN-driver software, typically a fixed data structure with 8 byte is used to store 0 to 8 bytes of data, because the overhead in data structure is more than 8 bytes. To have a fixed data-structure with 64 byte will be a significant loss of data space if most CAN-frames are less than 8 byte. The size of the data structure also makes it interesting to keep the data structure in one location and only transfer a pointer to this storage.

It is also necessary to define if it is allowed to use data-lengths that do not match the exact number of data bytes corresponding to the DLC coding. As seen from the table 2 is there a direct relation between the DLC value and the number of the data bytes in the CAN frame in the range [0 … 8]. For the DLC value in the range [9 … 15] it is necessary to covert this number into the actual number of bytes that will fit the CAN frame. This matching of data to the data length in the CAN FD frame is something that must be defined.

The last problem to secure in the driver is the bit-rate settings. Firstly, CAN FD makes it possible to have more time quanta. In the old standard the number of Time Quanta (TQ), in a nominal bit was in the range of 4 to 25 TQ. In CAN FD, this is increased a range of 4 to 161 TQ for the nominal bits. The data-bits in the high bit-rate continue to use a lower number of TQ i.e. 4 to 25 TQ. Even when the number of parameters remains the same, the size of each parameter is increased for the nominal bit. To handle both bit-rates it is necessary to set both bit-parameters: one for the nominal bit and one for the data-bits. It is to be expected that different CAN controllers have different sized parameters and even different interpretations of the parameters. Some CAN controllers will have two bit-rate prescalers, one for each bit-rate, but others will use the same prescaler for both nominal- and data-bits.

CAN FD demand a stricter configuration of the nominal bit. Please consult your Physical Layer expert for the correct configuration of both the nominal and data-bits

.

The data communication security engineer

In most cases, data integrity and security are combined, but I have decided to split them in this discussion. Even if they have much in common, their purpose is different. For me, data security protects data from being manipulated within the system as CAN bus is used for machine control, not for sending secret documents or information on financial transactions. Whilst there is information within the CAN communication that could be sensitive, such as GPS-position, speed, time etc., that information is simple to obtain by other means and protection of the CAN bus will not solve that problem. The main challenge for system security is to protect the CAN communication from aliens sending wrong information into the system or taking control of the system. Systems are at their most vulnerable when electronic units are updated with new software. So firstly we would like to protect the software from reverse engineering and secondly from being replaced by alien software.

CAN FD allow more data in every CAN-frame, which simplifies the transfers of files and long keys. However, CAN FD does not add any other features that aren’t present on Classical CAN.

The data communication integrity engineer

In most cases, data integrity and security are combined, but I have decided to split them in this discussion. Even if they have much in common, their purpose is different. For me, data integrity is there to protect the data from being modified by disturbance between the sender and the receiver. This is normally a very limited problem in a real-time control-system, because even if you get a bad value, it will be replaced with a new value within a few milliseconds.

CAN FD have better protection against undetected errors in the data. To get undetected errors demands CAN communication with a high Error-Frame content. The best way to protect the communication is to improve the physical layer to remove any occurrence of Error-Frames.

If it is not possible to reduce the rate of Error-frames to a safe level, CAN FD will decrease the risk of undetected data errors.

The physical layer engineer

For physical layer engineers, CAN FD is identical to Classical CAN as long as there are no demands to increase the bit-rate in the data-part.

If there is demand for an increase to bit-rate, life gets more complicated. It’s best to look at the CAN bus signal with an oscilloscope. If the signal is nice and square, there’s no reason not to increase the bit-rate by 2 to 4 times that of Classical CAN. Notably, it is necessary to perform measurements at different locations along the CAN bus wires. The signal can be nice and square in one location and have a serious ringing at another location. The arbitration is relatively demanding and if it works with a certain nominal bit-rate, it’s possible to increase the data-rate by 2 to 3 times the arbitration bit-rate without any problems. Beyond 4 Mbit/s, the CAN drivers in use today won’t perform correctly because the dominant signal is ‘sticky’. If the CAN driver sends 5 dominant bits in a row, it will stick to the dominant level and the following recessive bit will be shorten.

There are three limiting factors to the bit-rate;

1. The need to have continuous impedance throughout the CAN-wires.
2. CAN drivers with fast slew-rate.
3. CAN driver with symmetric bits.

Impedance

It is very easy to get a cable with continuous impedance, because as long as the cable does not change its physical dimension in the cross-section and use an isolation with a homogeneous dielectrically constant, there will be no change in impedance. The problem is the connectors in the end of the cable. This is solved in USB and Ethernet by using dedicated connectors that have been designed to match the cables. When using higher bit-rates every cable split, connector and drop line will pose a challenge because of the impedance variations causing signal reflections. Those combined energy reflections will result in the oscillation at the edge of the bit.

The CAN driver

CAN drivers are available that are suitable for higher bit-rates. Those CAN drivers will work up to 10 Mbit/s in the lab. The bit-rate achievable in a real installation over the expected temperature range requires validation by test in a real installation under all working conditions.