Updated on Jan 13, 2025
What is CAN bus? If you Google “CAN bus,” the answer you’ll get from Wikipedia is: “A controller area network (CAN) is a vehicle bus standard designed to enable efficient communication primarily between electronic control units (ECUs).”
All clear? Don't worry – you’re not the only one. Unclear information in the market about CAN bus has caused some confusion. Contractors are unsure about the data CAN bus provides as well as how this data can fit into their equipment management systems.
In this post, we’ll try to clear up the confusion by taking a closer look at:
- What is CAN bus?
- How does CAN bus work?
- What information contractors can get through CAN bus?
- How contractors can use this data to make more informed decisions.
Understanding CAN bus
So, what IS CAN bus? An easy way to think about CAN bus is as the nervous system of a heavy truck or piece of equipment. Just like the human nervous system sends messages between body parts, CAN bus does the same for electrical systems (or ECUs). It connects and relays messages between different ECUs, like the engine, transmission, brakes, and body.
These different ECUs work independently. However, a heavy truck or piece of equipment needs them to communicate properly in order to work together. For example, if your anti-lock brakes fail and the other systems do not notice, you might not get the warnings you need, which could prevent you from getting repairs done.
Just like your body’s nervous system sends pain signals to warn you, CAN bus helps systems gather data. It uses sensors to take action when needed. For example, CAN bus can warn operators about problems with traction control systems or help engage four-wheel drive in slippery conditions.
The result? Vehicles and equipment can work better, and mechanics can diagnose, maintain, and sometimes fix these machines remotely using software. Impressive, right?
So why is it important for contractors to better understand how CAN bus works? Because in heavy equipment and fleet management, this flexible communication method provides great benefits through data.
And by utilizing construction analytics, this data can be transformed into insights that enhance:
- On-site decision-making
- Maintenance scheduling
- Resource allocation planning
- And so much more
How does CAN bus work?
We'll dig into these benefits further, but first, a quick explanation of how this technology works.
CAN bus has several key purposes. It sends messages to different parts of a vehicle or equipment and also retrieves information from these parts. Additionally, it helps with everyday tasks, from unlocking doors to showing speed on the speedometer.
Cars and light trucks use CAN-based On-Board Diagnostics (OBD-II), while mid- and heavy-duty vehicles use a different protocol called SAE J1939 or JBUS. While you might not know about CAN bus, you have probably used your OBD or JBUS port. These ports, called Diagnostic Link Connectors (DLCs), enable collecting diagnostic trouble codes (DTC) when a machine's check engine light is activated, for example.
For an OBD system, the standard specifies PIDs (Parameter Identifiers) for different sensed data elements. For instance, PID 13 provides the vehicle's "wheel-based speed," represented as a single byte, ranging from 0 kph to 255 kph. This value is shown on the speedometer and used by asset trackers for many purposes.
In J1939, these parameters are called SPNs for “Suspect Parameter Numbers,” but they fulfill a similar purpose.
Applications of CAN bus for Construction Companies
So, what is CAN bus or what details can the CAN bus usually offer? The CAN bus gives access to important sensor information and system settings, which can help contractors better understand how assets are performing. This level of detail is extremely useful for equipment and fleet managers to improve operations, carry on routine maintenance, and find potential problems.
A non-OEM CAN tracker can only give generic J1939 or OBD standard data types defined by those respective standards. This data may include RPM, speed, engine hours, coolant temperature, engine oil temperature, fuel flow rate and much more.
Contractors can utilize third-party trackers, such as Tenna’s CANbus tracker, to obtain OEM-approved data. It’s important to remember that the data available is only what OEMs provide in either standard J1939 or OBD formats. The availability and quantity of data often correlate to the year, make, model, trim and accessory loadout. The engine and Engine Control Unit (ECU) type further determines what format and data complement one can expect to be available.
Since the CAN bus offers many data points, equipment and fleet managers can focus on what matters to their work. For example, California contractors may want to track idle time. This can help reduce wasted resources and meet air quality rules. This adaptability enables the creation of more focused and customized tracking solutions.
Additional potential applications include tracking fuel usage, battery status, error codes, DEF levels, and PTO activity. These metrics enable construction equipment managers to make better decisions about rentals, replacements, preventive maintenance, resource distribution and other factors.
What information can you not get through CAN bus?
We’ve talked about what CAN bus is, but what about what CAN bus is not?
Some manufacturers make use of proprietary diagnostic port data formats that are different from OBD and J1939 (and the older J1708 format). These are non-CAN bus ports, and, therefore, a CAN bus scanner or tracker cannot read these ports.
These ports often have CAN bus ports with limited functionality present on the same connector but require special adapters to access the CAN functionality.
Fuel Consumption
JBUS options for determining fuel consumption include engine trip fuel or trip fuel (gaseous). Both parameters will generate estimates—good estimates, but estimates, nonetheless. There is also fuel tank level. From this, usage rates can be estimated. There are several SPNs dedicated to fuel.
For OBD II, the choices are far more limited. There is no fuel consumed PID. So, GPS trackers must use other metrics to estimate fuel consumption. While no method exists to measure precisely how much fuel users consumed in OBD II, a reasonable estimate can be provided. Again, tank level is available, so by knowing tank size, contractors can index rate and determine usage.
One common method uses the Mass Airflow Rate multiplied by the runtime to get the total trip air consumed, then calculates fuel burned in driving. This calculation applies the known air-to-fuel ratio for the type of fuel used on a trip.
The Mass Airflow Rate-based calculation also needs to account for variables like ambient temperature, fuel temperature and other factors. This exercise is more complicated because some OEMs do not always provide Mass Airflow Rate data for all models and years.
Another option is to use Fuel Flow Rate, or fuel injector flow settings, but these are even less commonly reported than Mass Airflow Rate.
As you can see, while you can estimate fuel consumption through the CAN bus for many assets, the data is not guaranteed to be available for all assets.
PTO (Power Take Off)
Many types of equipment implement a PTO mechanism. For OEM installed PTOs, PTO state or operation time may be reported through their CAN bus interface. This approach is increasingly common but is not guaranteed to be available in all equipment.
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, since they were not built into the equipment originally.
Some equipment only reports total PTO time. This means you need to do calculations to find the current state. For others, the tracker reports only the PTO state, and the PTO time must be totalized in your database.
A tracker must choose the right data processing method based on the available data source to ensure accurate results. So, like fuel consumption, PTO is not a reliable data point for CAN bus in that it is not guaranteed to always be available.
Seatbelt State
Seatbelt state is another parameter most OEMs do not broadcast over CAN bus. 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.
Similarly, the monitoring device must be configured to read these SPNs and their alternates to capture state changes.
Proprietary Bus Formats
Some vehicle and equipment makers, like Liebherr, John Deere and Komatsu, use a special version of CAN bus. This version sends codes that do not follow the standard JBUS SPNs or the signals are not formatted electrically according to CAN bus conventions. As a result, these parameters are not visible to code scanners, dataloggers or asset trackers.
Some manufacturers offer an extra JBUS port on some models of their equipment. However, these ports usually provide only a few of the parameters available from the main proprietary port. Standard code readers, dataloggers and asset trackers can only see a few operating parameters of equipment. In many cases, they see none at all.
Choosing the Right Tracker for CAN bus Data
If this seems complex, here’s some good news: understanding CAN bus is easier than it looks.
CAN bus provides access to a lot of data that can help contractors analyze equipment performance, asset usage and other important metrics. In simple terms, CAN bus data is a game-changer for construction companies. It helps them improve productivity, efficiency, and business growth.
What’s important to remember is that data access depends on the tracker and the specific CAN bus system of the asset. Different trackers have different configurations and can access different data through CAN bus. Additionally, various equipment manufacturers follow different protocols for the data they make available.
Picking the right tracker for your assets is key to making the most of your equipment’s CAN bus protocols.
Tenna’s team can help you choose the right tracker combination for your operations and help you better understand how to leverage this data.
About Mark Leszczynski
As Director of Hardware Products at Tenna, Mark is passionate about developing new construction-focused hardware solutions and utilizing emerging technologies to help existing products evolve.