CAN (Controller Area Network) Gateway Design Considerations

While designing the jCOM series of CAN / SAE J1939 to USB gateways, we have thrived to accomplish maximum performance at the lowest possible price. While this statement may appear contradictive, we believe that we have created the perfect compromise (See also my post  Turbo CAN Bus, SAE J1939 Board For Raspberry Pi, BeagleBone, Arduino, and Android Systems).

So, what is a “perfect” CAN gateway? Well, such a device could reliably process a CAN baud rate of 1 Mbit/sec at 100% busload. To say it upfront, our devices do not match these requirements, nor does any gateway in the marketplace.

One reason is that these requirements are unrealistic (as I will explain in the following chapters); another is that real-world applications are not as demanding. For instance, SAE J1939 uses only a baud rate of 250 kbit/sec, and our gateways are quite capable of handling busloads close to 100%.

There is also the issue of the limited CAN network length. A baud rate of 1 Mbit/sec limits the maximum network length to roughly 120 feet (40 meters), and that can only be accomplished through meticulous network design (think coax cables, proper termination, etc.).

The main use of CAN/J1939 gateways is generally monitoring data traffic through a host system (e.g., a PC running Windows or Linux), and that includes mostly a limited subset of data by applying message filtering. For simulation and prototyping, you might also want to transmit messages into the bus. All this (and more) is, of course, effectively supported by our gateways.

Add to all this, that even the most powerful PCs in the market would have major problems when confronted with a 100% CAN bus load at 1 Mbit/sec. It’s not impossible, but it would require major software tweaking. Now consider using popular systems such as the Raspberry Pi, BeagleBone, Arduino, etc., embedded systems that, while shining through a great price/performance ratio, would be easily overwhelmed.

Be that as it may, when it comes to supporting a CAN or SAE J1939 application, we didn’t want our gateways to be the acting bottleneck. Thus, we have put a lot of thought into the proper design of a CAN/J1939 gateway, as explained in the following.

CAN Bus Load Considerations

Theoretically, any certified CAN bus controller can process a busload of 100%, which translates into continuous data traffic without any delay between message frames (message latency). However, in the real world, the maximum busload depends on the design of the individual nodes in the network. The main issue is the time that it takes the processor to remove message frames from the CAN controller (e.g. while it is busy transmitting an RS232 data frame).

In other words, the maximum busload is not a CAN bus issue but a system performance question. Any “lack” of system performance will result in a delay between message frames. In all consequences, a busload of 100% can hardly be accomplished. Naturally, the impact of system performance is greater at the maximum baud rate of 1 Mbit/sec than at any lower baud rate.

According to experts in the CAN industry, the average busload in a CANopen network is 40 to 50%, and the maximum is about 70 to 80% for short periods of time. In regard to SAE J1939, a 70% busload is considered a maximum value.

However, heavy bursts of messages can occur on the bus, leading to 100% busload during the burst (which will delay low-priority messages). As a result, any CAN node should be able to process random data bursts (through proper message buffering). In the case of SAE J1939, the compliance test procedure (SAE J1939/82) dictates that a node must be able to process a data burst of 20 messages within 10 milliseconds.

As a result, the design of a CAN gateway should include:

• Sufficient message buffer size
• Sufficient communication speed on the USB side

USB Port Speed

In order to reduce any message latencies, the non-CAN side (USB) should support transmission speeds close to (if not better than) the maximum CAN baud rate of 1 Mbit/sec. In case of the jCOM.CAN/J1939.USB gateways, we are using a UART to USB converter with a maximum rate of 921,600 baud, translating into 92% of the CAN maximum speed.

We chose this particular converter due to various reasons:

• Low price
• Driver performance
• Support for operating systems (including their various derivatives) such as Windows, Linux, and Android

There is no need to explain the price advantage (which is significant), so let’s address the driver performance and OS support issues:

While USB (specifically USB 2.0 and 3.0) can support much higher baud rates than 921,600, we have run into some strange performance issues, which effectively eliminated the speed advantage. This could only be explained through inefficient driver design. In this case, we tested recommended, standard USB controllers only to find that their drivers were either poorly designed or were not available for operating systems other than Windows (thus effectively ignoring the Linux and Android community).

The combination we are using, i.e. USB hardware plus driver, satisfied our demand for ease of implementation and use, while effectively supporting the vast majority of CAN and SAE J1939 applications.

CAN Message Length Considerations

To compensate for the speed difference, we deemed it possible to reduce the size of the message frame on the USB side.

Let’s have a look at the possible CAN message lengths:

• Message frames with no bit stuffing: 47 bits (0 data bytes) to 111 bits (8 data bytes)
• Message frames with average bit stuffing: 49 bits to 114 bits
• Message frames with maximum bit stuffing:  55 bits 135 bits

Note: The above message length table applies only to CAN 2.0A messages, i.e. an 11-bit message identifier. In contrast, SAE J1939 uses 29-bit message IDs, but with a baud rate of 250 kbit/sec, there are no real speed issues.

In our jCOM protocol, we have managed to reduce the message frame size by 15% in the worst-case scenario and 72% in the best-case scenario.

The Processor

Most of our jCOM gateways use the NXP LPC1754 (yet again, due to price considerations), an ARM Cortex-M3 microcontroller with a clock speed of 100 MHz. However, if we need more than one CAN channel and/or an Ethernet port, we will prefer the NXP LPC1768.

Internal tests have shown that both processor types can retrieve data from the CAN controller in the shortest time. In addition, all CAN data transmission and reception are interrupt-driven, and the firmware supports a buffer for up to 50 CAN message frames.

A Comprehensible Guide to Controller Area Network by Wilfried Voss represents the most thoroughly researched and most complete work on CAN available in the marketplace.

Controller Area Network (CAN) is a serial network technology that was originally designed for the automotive industry, especially for European cars, but has also become a popular bus in industrial automation as well as other applications. The CAN bus is primarily used in embedded systems, and as its name implies, is a network technology that provides fast communication among microcontrollers up to real-time requirements, eliminating the need for the much more expensive and complex technology of a Dual-Ported RAM.

This book provides complete information on all CAN features and aspects combined with a high level of readability. => Read more...