CAN Bus Bursting

This was copied from a document here

By Chris Uustal - 7/22/22

### Purpose

This document outlines the idea behind and implementation of CAN bursting--an approach for rapidly updating a value or set of values on a vehicle CAN bus as a result of one or more events or conditions being met.

### Idea

The core idea behind CAN bus bursting, also just known as bursting, is that you want to get all the benefits of getting data as often as you need it without the downsides of sending too much data when you don’t need it.

As some background, most CAN messages are sent at a regular interval like 100ms, and usually this interval is selected to be as long as possible while still meeting its functional requirements to avoid wasting processing time sending signals unnecessarily and to keep more available overhead on the bus. However, there are certain situations where you may want some message to be sent at a much faster rate, but only during that specific situation.

### Implementation

Let’s say for example the team decides to implement traction control--in most situations, the traction control system shouldn’t be doing anything other than watching (since we have no issues with traction most of the time). This means most of the time it will be sending the same value (0), so it would be a waste to have it send it at a very high rate. However, when traction control does want to reduce the amount of power going to the wheels, it should do that at a very fast rate to be the most effective. While you could trivially attempt to solve this by just always sending a traction control signal every 10ms with the updated traction control value, this now means we have at least a few hundred bytes per second of wasted data that we didn’t really need to send. Instead, you could have the traction control system send a message every 1 second when it isn’t doing anything (just to let the other devices know it’s still there), then burst at 10ms whenever it does want to engage traction control. This means in most situations you’re only wasting a few bytes per second, but you’re still getting the granularity of control you need when it matters.

### FAQs

One note you may have is “well if we already have the space on the bus for us to burst without an issue, why didn’t we just send it at that fast rate all the time?”. While that line of reasoning does make sense for a bus with only one signal that’s being bursted, what if most of your signals work on some kind of bursting methodology? Then, assuming most devices won’t be bursting simultaneously, you can have a bus which supports a theoretical data throughput which is significantly higher than its actual throughput simply because it’s assumed that these bursts will predominantly happen asynchronously from each other.

Another application note is that, not only does this allow for greater theoretical throughput on your bus through widespread application, it also allows you to maintain smaller memory buffers and more efficiently utilize processing cycles on all the devices connected to the bus. This is because every message a microcontroller has to process takes up some amount of space in their buffer (which may be significant) and takes cycles on the processor to interpret--these cycles could have been used doing other tasks and this buffer space could be used to reduce the rate at which the buffer is read. The general idea here is that you should be sending as little unnecessary data as possible while still remaining functional.

Reading the above, you may be tempted to take this application to the limit by simply not sending messages unless they have new information, and sometimes that is a valid approach, but it’s usually not worth the downsides from a data confidence and reliability standpoint. Some issues that can arise from this is that there are certain situations where controllers will miss messages--if something isn’t repeated until it changes, then one or more controllers may have missed critical information. Similarly, if someone is attempting to debug the vehicle and connects in the middle of operation, they may not have any way of understanding the current state of some sensor until it changes--if this is something like the drive gear of the vehicle, it doesn’t make sense that the tester would have to put the vehicle into drive and back into park to see it was originally in park. It makes much more sense to simply periodically send information about the current state of the vehicle, even if at a somewhat slow rate. The bus overhead costs are minimal but the functional gains are significant. Additionally, not all microcontrollers will begin operating at exactly the same time when the vehicle starts up (different lengths of startup code), so we don’t want some controllers to miss critical information about the initial state of the vehicle at startup. This also applies if a microcontroller is reprogrammed while the vehicle is on. As mentioned, there are certain situations where not sending a signal at all nominally may make sense (eg. a vehicle crashed signal)--these are conventionally called “alerts”, but these are usually the minority of signals being sent on a vehicle bus compared to the control and data signals being sent.