“A Controller Area Network is a robust vehicle bus standard designed to allow microcontrollers and devices to communicate with each other's applications without a host computer.” If you Google “CAN bus,” that’s the answer you’ll get from Wikipedia. All clear? We didn’t think so either. But CAN bus is also essential to the daily functionality of Tenna and other data-oriented systems. So let’s take a closer look:
- What is CAN bus?
- How does CAN bus work?
- What information can you get through CAN bus?
- What information can you not get through CAN bus?
What is CAN bus and where is it used?
Some people compare CAN bus to the nervous system of a vehicle. Just like the human nervous system connects and relays messages between the various organ systems, the Controller Area Network—or CAN bus—connects and relays messages between the various electrical systems in a vehicle.
Modern vehicles operate with electronic control units (ECUs). The largest of these is the Engine Control Module (ECM), but others include ECUs for transmission, safety, and entertainment. Think about the components of your current vehicle: airbags, anti-lock braking systems, cruise control, power steering, audio and video systems, power windows and doors, and even mirror adjustments. Remember cranking up car windows by hand? An ECU replaced that.
These various ECUs are mainly independent of each other, but the safe operation of a vehicle depends on them being able to communicate with each other. If your anti-lock brakes go out and the rest of the vehicle systems are oblivious, you won’t get the warnings necessary to get the vehicle off the road and in for repairs. Similar to the way your body’s nervous system relays pain or other symptoms to alert you that something is wrong, CAN bus allows these independent systems to send and receive feedback from sensors that alert drivers to potential problems.
The result is vehicles and industrial machinery that can be diagnosed, maintained, modified, and sometimes repaired by software alone.
How does CAN bus work?
CAN bus can be used for sending messages to the various modules in the vehicle, reading data back from those modules, and facilitating many common operations like unlocking doors and displaying speed on the speedometer.
Generally, CAN-based On-Board Diagnostics (OBD) is used in cars and light trucks. A different protocol called SAE J1939 (JBUS) is used in mid-duty and heavy-duty vehicles such as heavy trucks, cranes, bulldozers, semis, and many other types of equipment. While you may not be familiar with CAN bus, you have likely used your OBD or JBUS port, even if you’re not currently using GPS trackers in your vehicle. These ports are also used to interpret diagnostic trouble codes (DTC) when your check engine light is activated.
In the case of an OBD system, there is an associated PID (Parameter Identifier) for every piece of data being made available. For example, PID 13 supplies the vehicle’s “wheel-based speed” as a single byte representing 0-255 kph. This value is what appears on the speedometer and is used by asset trackers for many purposes—such as detecting hard driving events by calculating the acceleration/deceleration of the vehicle from speed changes over time.
(See this resource for a complete list of PIDs.)
How does CAN bus work with Tenna?
A Tenna OBD tracker reads these PIDs and their metadata and reports this information to Tenna’s back end over the cellular network. In other words, every piece of data you receive through Tenna about the operations of a piece of equipment or a vehicle comes from individual systems within your asset communicating through CAN bus.
In the JBUS world, PIDs are referred to as SPNs (Suspect Parameter Numbers). Typically, these SPNs provide detail on fuel usage, RPM, and other variables. As with OBD systems, this data is reported to Tenna’s back end over the cellular network.
It’s not uncommon for there to be broad claims about the type of data that can be gathered through CAN bus, but it’s important to remember that data access is limited to the capabilities of both the tracker and the proprietary CAN bus system of a particular asset. Different trackers have different configurations and can access different data through CAN bus. Additionally, various equipment manufacturers have different protocols for the data that is made available.
Therefore, picking the right tracker for your asset, and understanding what may and may not be available through a particular asset’s CAN bus, can alter the data you are able to gather about a particular vehicle or piece of equipment.
What information can you get through CAN bus?
Commonly available parameters typically include:
|
|
These parameters can generally be counted on to be available to code readers, dataloggers, and asset trackers.
What information can you not get through CAN bus?
In general, CAN bus cannot access certain parameters that are manufacturer-specific such as:
- Fuel Consumption
- Power Takeoff
- Seatbelt Status
- Proprietary bus data
Additionally, the use of CAN bus interface as a primary power source is severely limited.
Fuel Consumption
JBUS options for determining fuel consumption include Engine Trip Fuel or Trip Fuel (Gaseous). It’s important to note that both of these parameters will generate estimates—good estimates, but estimates nonetheless.
For OBDs, the choices are far more limited. There is no Fuel Consumed PID, so GPS trackers must use other methods to arrive at a fuel consumption estimation. (Like JBUS, there is no way to exactly measure how much fuel was used.) One popular method uses the Mass Airflow Rate to calculate running fuel usage, which is then added to arrive at a total fuel usage figure for a trip. This calculation requires knowledge of the air-to-gasoline ratio needed to sustain combustion, which is different for different fuel types (diesel, propane, gasoline, others).
The Mass Airflow Rate calculation also needs to account for variables like ambient temperature, fuel temperature, and other factors. Adding further complication to this exercise is the fact that certain OEMs (Ford, for example) do not reliably provide Mass Airflow Rate as a data source in all models/years.
Another option is to use Fuel Flow Rate), but this is even less commonly reported than Mass Airflow Rate.
Some years ago, Tenna faced a situation in a customer’s fleet where some Ford 2012 F-150 pick-up trucks reported fuel consumption directly, but others within that same make/model/year did not. The issue was traced to the truck OEM’s spotty support of Mass Airflow Rate.
As you can see, fuel consumption via CAN bus can be estimated on some assets but is not a reliable data point for CAN bus.
PTO (Power Take Off)
Many equipment types that are physically capable of PTO will report the PTO state or time of operation via their CAN bus interface, but many others will not. Typically, assets that are older than 2014 do not have this functionality.
Equipment with aftermarket PTO devices generally do not report their PTO state over the CAN bus. Also, even for those types of equipment that do report PTO over CAN bus, some only report accumulated PTO time versus the state of the PTO, requiring calculations to determine the current state. For others, only PTO state is reported, requiring the tracker to calculate the PTO time.
A tracker must be able to properly select the appropriate data processing method given the available data source, and this must be done carefully to ensure accurate results.
Like fuel consumption, PTO is therefore not a reliable data point for CAN bus.
Seatbelt State
Seatbelt state is another parameter most OEMs do not broadcast over CAN bus. Indeed, there is no standard OBD PID that reveals seatbelt status. For JBUS, there are SPNs for this purpose, but they are only available if provided by the OEM equipment.
No PID nor any SPN is ever guaranteed to be available in any equipment.
Proprietary Bus Formats
Some vehicle/equipment OEMs (such as Liebherr, John Deere, Komatsu, and others) employ a proprietary variation of CAN bus that issues codes that are not compliant with the general JBUS SPNs. As a result, these parameters are not visible to code scanners, dataloggers, or asset trackers. Some manufacturers do provide an alternate JBUS port on certain trim levels of their equipment, but these implementations generally provide only a small subset of the parameters available from the equipment’s proprietary port.
Standard code readers, dataloggers, and asset trackers have only limited visibility to many equipment’s operating parameters, if any at all.
Picking the right tracker for the right asset is key to making the most of your equipment’s CAN bus protocols. Tenna’s team can help you choose the right combination for your operations. Take a look at our options and book a demo to find the right fit for you.
