Challenges your Automotive Team may Confront During Migration from CAN 2.0 to CAN FD

Challenges your Automotive Team may Confront During Migration from CAN 2.0 to CAN FD

Imagine a scenario where a car driving on a slippery road loses traction and starts to skid. In such an emergency situation, the built-in Electronic Stability Program is required to get into the action.

This program will need to detect the vehicle speed and the torque on each wheel, at real-time, to take corrective measures.

CAN 2.0 protocol, with its 8-bit data rate and lesser payload capacity, may not be the best solution for such applications.

For such data-intensive applications that call for faster response times, CAN FD (Flexible Data Rate), a successor of CAN 2.0 protocol, has been developed.

In the era of ADAS, Remote Diagnostics and other connected car applications, the need for migration to CAN FD is being felt by technology teams across the globe.

This transition has its own set of challenges, which we will discuss in detail.

So before kick-starting your CAN FD migration project, do read about these personal experiences of our Automotive Product Engineering Services team.

Migration of Existing Application from Classical CAN to CAN FD

Before we start to explain this scenario, it is important to highlight the architectural difference between CAN 2.0 and CAN FD.

The increase in data transfer rate and payload capacity in CAN FD is brought about by the change in the data link layer and the physical layer. The CAN messages that had to be split because of 8 byte payload limitation in CAN 2.0, can be combined into one message in CAN FD protocol.

Major Differences in CAN 2.0 and CAN FD

Classical CAN or CAN 2.0	CAN Flexible Data
Data bit rate is max 1 Mbps	Max data bit rate is 8 Mbps
A maximum of 8 bytes of data can be sent in one frame without Transport Protocol	64 bytes of data can be sent in one frame without the TP layer.
Multiple CAN nodes can broadcast message frames.	Only one node transmits at a time; one of the reasons for increased bit rate
No BRS or FDF to switch the speed to higher or lower levels	Bit Rate Switch (BRS), Flexible Data Rate Format (FDF) and Error State Indicator (ESI) together ensure higher speed.
Cyclic Redundancy Code contains a 15 bit code	CRC field has 17 or 21 check codes
Less secured due to less data payload capacity	Enhanced security of data as CAN FD data can be encrypted using the extra memory

For an application to be migrated to CAN FD from Classical CAN, the data link layer needs to be first made compliant with CAN FD.

The data link layer comprises of the ISO Transport Protocol (TP) layer as well as the CAN FD device drivers.

Hence, the migration in this scenario is a 2-step process.

1. ISO Transport Layer Development Based on CAN FD Document

   In case of CAN 2.0, the transport layer can receive or transmit data length in tune of 256*16. However, CAN FD transport layer is capable of receiving/transmitting data length of much larger size i.e. 2^32-1.

   Hence, to support the 64 data bytes payload and CAN FD message frames the automotive software team will have to make relevant changes in the Transport Layer. The changes in the TP layer is made according to the standards mentioned in the CAN FD documents.

2. Developing the CAN FD based drivers for the microcontroller family

   In order for the microcontroller to receive and transmit CAN FD data frames, the CAN FD drivers are written w.r.t the MCU family. The Bit Stream Processor is the component tasked with receiving/transmitting CAN FD frames. Separate drivers are required for each of these components to function.

Need for External CAN FD Controller

At times, there are certain legacy microcontrollers that do not support CAN FD protocol.

One solution is to replace the entire MCU with a CAN FD supported microcontroller. However, changing the entire MCU hardware may not be a viable option. This would mean following the entire process of device driver development, integration and testing. The escalated cost and time-to-market can have a major impact on the ROI.

A better and one of the most widely used methods to make such systems CAN FD compatible is to add an external CAN FD controller. These controllers act as slave devices and communicate with the vehicle network on behalf of the main control unit.

The automotive ECU communicates with an external CAN FD controller using Serial Peripheral Interface (SPI). The communication starts by application asking for some vehicle parameter say engine speed. The transceiver in the MCU will interface with the external CAN FD controller.

The external controller, on the other hand, will act as a CAN FD engine. It will process the CAN messages from the vehicle and pass any relevant information to the MCU.

The role of the automotive software developers here is to develop the SPI based drivers to help the MCU communicate with the external CAN FD controller. Device drivers, as well as, low-level drivers also need to be developed for this slave device.

Mixed Networks and Partial Networking

Mixed networks where both CAN 2.0 and CAN FD nodes exist, on the same network bus, are quite common. Although CAN FD transceivers are compatible with Classical CAN, the data link layer is not.

This implies that if a CAN FD node sends a signal, the CAN 2.0 node will not be able to receive it, causing error and interruption in the communication.

One of the most widely used methods to fix this compatibility issue is partial networking. The partial networking functionality makes use of a CAN transceiver standard, called CAN with selective wake.

When a CAN FD is communicating, the CAN 2.0 nodes are passive i.e. invisible to the network. This condition is akin to putting the CAN 2.0 nodes to sleep while CAN FD communicates. However, the CAN 2.0 nodes are not completely inactive; they are selectively awake.

A Partial Networking (PN) transceiver comes into picture in such a scenario. This transceiver keeps the CAN 2.0 disconnected from the network during CAN FD communication. As soon as a valid CAN 2.0 wake up message appears, the transceiver will wake up the CAN 2.0 nodes and route the message to them. It is interesting to note that this wake up message frame is sent by CAN FD node itself.

“There is a power factor associated with partial networking too. When the CAN 2.0 nodes are made passive, they enter a low-power mode. In electric vehicles, this helps save a fair amount of battery power as well. “

Conclusion

CAN FD not only ensures high speed data transfer but also does it securely. With the emergence of concepts such as telematics, connected cars, and remote ECU reprogramming, security has been a major issue. Also, the update size for certain applications have become larger and frequent.

CAN FD is able to handle both these issues efficiently. And with swift migration of applications to CAN FD, the complete transition from Classical CAN to CAN FD will soon be a reality.

This entry was posted in Embedded Blog, Blog by Embitel. Bookmark the permalink