Behind-the scenes operator: CAN’s role in embedded control

Though the systems that Controller Area Network (CAN) is integrated into make headline news, CAN rarely gets a mention these days. Whether you are at CES, Embedded World or the Autonomous Vehicle Technology Expo, you’ll see self-driving vehicles and concept cars with CAN embedded so deeply that it’s a challenge to find out if it is indeed there – it may well even be shielded from the OEM.

Nevertheless, CAN is present, doing its job deeply, because somewhere along the line, it’s necessary to communicate relatively short data packets extremely reliably. With an installed base that runs into the billions of units, CAN is a proven network technology that is as relevant in the future as it is today.

An introduction to CAN

Designed by Bosch in the 1980s for safety critical systems in the automotive industry, CAN offers some unique features that make it widely applicable in any safe and secure control system. Among these are:

Reliability: CAN is widely considered one of the most reliable methods for transmitting real-time data. The CAN protocol determines the priority for each message being sent, allowing for an easy, uninterrupted flow of communication, even when multiple messages are being sent simultaneously.

Data consistency: This is guaranteed in a CAN system because every node receives the same messages and all the nodes check that the message is correct before they accept it. ‘Cast-iron’ data consistency is a mandatory requirement of any safe security system, and CAN offers a particularly elegant way of satisfying this requirement.

Guaranteed latency: In CAN, a high-priority message can be transmitted at once and bitwise arbitration will resolve any message collision in a predictable way. A CAN system with 25 nodes guarantees a latency of less than 0.25 milliseconds for a high priority message. In contrast, standard Ethernet is unable to guarantee latency. Work-arounds involve installing dedicated Ethernet networks for closed loop control, but ultimately, these can be costly.

An efficient addressing method: CAN has no addresses but an identifier for the message content, allowing for very short messages, i.e. just a content identifier and a value. As such, all connected CAN modules receive every message and it is up to the receiver to select the right message to process. The transmitting node does not need to know who should receive the message and the receiving node does not need to know the message source. At the same time, CAN ensures that all receivers get identical data to synchronized decisions across all units. This is an extremely efficient way of setting up connections in a control system, enabling point-to-point, multicast and broadcast messaging schemes to be created with ease. CAN’s unique addressing method provides high levels of system and configuration flexibility: adding and subtracting CAN nodes requires zero hardware or software modification.

Network-wide error detection: In CAN, all nodes participate in the error detection process. If any node detects an error, all nodes delete the message before it is available for the application, and by that ensure that no unit processes different data. The transmitter then retransmits the message, resulting in a maximum latency of a retransmittion that is within a fraction of a millisecond at CAN’s higher bit-rate.

The transition to CAN FD

CAN isn’t without its limitations. To provide real-time performance, the CAN bit-rate is limited according to the length of the bus wire. Also, package length is limited over time to ensure that low priority CAN-frames can’t delay high priority information. 

Therefore, a more powerful CAN protocol was developed by Bosch, in concert with several auto makers and CAN industry participants. CAN FD (Flexible Data-Rate), published in 2011, increases the bit-rate in the data section, making it possible to increase the number of bytes in the data section without increasing the length in time of the CAN-frame. This improvement in performance and bandwidth facilitates applications such as encryption, authentication and flashing, three key drivers behind demand for more data in each CAN-frame.

When comparing CAN and CAN FD, the main take-aways are as follows:

1. CAN FD has shorter CAN frames while increasing the bit rate. This lowers latency, improves real-time performance and increases bandwidth.
2. CAN FD can hold more data in the CAN frame: taking each frame from 8 to 64 bytes. With less relative overhead, you can expect better data throughput. When sending large data objects, you can rely on simpler, more efficient software.
3. CAN FD has a higher-performance CRC algorithm, lowering the risk of undetected errors.

Though not yet widely implemented, CAN FD is in active development with several large car manufacturers and has plenty of silicon support from Microchip, NXP, STMicroelectronics and Texas Instruments, among others. CAN FD’s increased performance and communication bandwidth make it an ideal middle ground between classical CAN and more complex protocols being implemented in modern vehicles, such as FlexRay and Ethernet.  

Among the most pressing reasons for the automotive industry’s transition to CAN FD is the necessity for security at all levels within the system. The argument that CAN has generally operated within a closed system, not accessible from the outside, is something that regulators are set to change. With up to 64 data bytes in a frame, CAN FD offers plenty of space for security signatures. As CAN FD begins to appear in mid-to high-end microcontrollers, built-in hardware support for security algorithms like the Advanced Encryption Standard (AES) is likely. Software solutions are available to secure CAN and CAN FD, such as ESAcademy’s CANcrypt, a security middleware that provides authentication and encryption for CAN FD.

CAN FD and Ethernet coexistence

So, why not simply use Ethernet, rather than CAN FD, when bandwidth is an issue? After all, it is now possible to run Ethernet at 5Gbps over four twisted pairs. The answer is in the idiom ‘horses for courses.’ Ethernet has its place when it is necessary to transfer a lot of information, but timing is not essential. It is also suited to dedicated point-to-point communications, where it is not necessary to compete for communication bandwidth, e.g. between a camera and the ECU that is processing the images. However, CAN was specifically designed for distributed embedded control systems, where data consistency and message collision resolution are required in a predictable way.

CAN could run at the same bitrate as Ethernet if CAN was specified to use the same physical layer technology (the lower the bit rate, the more robust the system, hence why CAN was specified with a low bit rate). Looking to the future, it is entirely possible that CAN and Ethernet could coexist on the same physical layer by, for example, putting CAN controllers into silent mode for a period of time, allowing the network to operate alongside Ethernet or another protocol for the exchange of non-control information. The use of high-speed protocols mandates the use of better cables and better cabling layout, which in turn could make the CAN control system even more dependable than today.

Looking to the future, what is clear is that CAN, like Ethernet, has not stopped evolving. Plans are afoot to increase the payload yet further, taking the maximum number of bytes from 64 for CAN-FD to as much as 4,096 bytes. Several methodologies have been proposed, but a key consideration will be the service organizations whose job it is to repair increasingly complex car communication networks. CAN’s proven robustness and use of cost-efficient, repairable cable remain highly-valued features.