Migration to CAN FD

CAN FD is now internationally standardized in ISO 11898-1:2015. We recommend migrating to CAN FD, even if you don’t need more bandwidth or a larger payload.

The benefits and challenges of CAN FD are different from the viewpoint of a device designer than a system integrator.

As a system designer, you always need more bandwidth. You want to integrate additional devices or extend the functionality of the already connected devices, which normally requires more bandwidth. With CAN FD you can double or quadruble the throughput – under specific conditions even more is achievable. If you want to add safety or security functionality to your system, a larger payload in the frames is helpful. CAN FD frames provide payloads up to 64 byte instead of the maximal 8-byte data field in Classical CAN. This should be sufficient for functional safety and security.

Of course, this has a price: You need to design your network more carefully, respecting the rules and guidelines of proper network topology. The chosen cable should have continuous impedance matching the impedance of the other physical layer components in particular of the devices’ CAN interfaces. The termination network should match accordingly. Additionally, you have to take care of the symmetry of rising and falling edges. And you should avoid ringing on the bus-lines as much as possible.

System designers using standardized higher-layer protocols such as CANopen or J1939 may benefit from new functions provided by CANopen FD (CiA 301 version 5.0) or J1939 on CAN FD (specified in CiA 602-2). CANopen FD introduces the USDO (Universal SDO) service featuring broadcast communication. The PDOs are also longer (up to 64 byte). CiA 602-2 allows more flexibility regarding the transmitted signals than SAE J1939-21 provides. The application layer protocol is Autosar-compliant, offering optional fields in the payload for safety and security. Of course, for the maximum benefit, this means changes in your application software. In many cases, the larger payload of up to 64 byte leads to simpler coding.

It is not necessary to migrate to CAN FD in one step. You can migrate step-by-step. First, use only the increased bit-rate and do not make use of the larger payload. The next step could be to add a small piece of software (gateway function) between your higher-layer protocol stack and your application. Of course, this is not an optimized solution, but requires just a minimum of change in your application software. The last step is to improve your software.

System designers can start the migration process right now, in order to be ready when your application requires it. Newly integrated devices should be prepared for CAN FD communication.

Be an early bird

Device designers should migrate to CAN FD as early as possible, in order to serve both markets: Classical CAN and CAN FD. Of course, you must change your hardware design: You need to select a CAN FD protocol controller and an appropriate CAN transceiver chip. It is recommended to implement transceivers qualified for 5 Mbit/s (this is the maximum bit-rate for which ISO 11898-2:2016 provides parameters). This is even a benefit when your customers want to use only 2 Mbit/s or less, because those components are more symmetric than the 2-Mbit/s qualified transceiver. This gives system designers more “freedom” for their physical network design. Additionally, device makers should make sure that all other components (e.g. connectors) have the same impedance as the on-circuit board and internal device lines. Of course, the drop lines should be as short as possible.

Software design requires the most changes. You have to update your software drivers and you need an additional protocol stack to make use of the up to 64-byte payload. CANopen FD, for example, specifies some new functions and is therefore not compatible to its predecessor. For customers who still want to use CANopen (CiA 301 version 4.2), you must provide a second protocol stack.

Something is missing

CANopen FD is coming. CiA has already scheduled an integration workshop and some members plan to exhibit a first prototype CANopen FD network at the SPS IPC Drives tradeshow in November 2016. There is still a lot to do: CiA 302 documents and conformance test plans as well as EDS specifications have to be reviewed, not to talk about all the CANopen profile specifications. The SIG motion control has already started to update PDO mapping for CiA 402.

Anybody interested in contributing to CANopen FD specifications is welcome. We also need more contributions for the system design, which will go into generic recommendations (CiA 601 series) and specific ones for J1939 (CiA 602 series) and CANopen FD (CiA 301). We miss you with your knowledge and experiences.

CiA expects think that in couple of years all CAN networks will be based on CAN FD. The car industry is already moving towards CAN FD. Therefore, most chipmakers will support CAN FD within the next two years. Transceiver chips qualified for higher bit-rates are already available. CAN FD tools are provided, too.