What Is CAN Bus?
The Controller Area Network (CAN) is used in e.g. automotives to allow communication between ECUs and sensors
- The CAN protocol is robust, low-cost and message based
- Originally developed by Robert Bosch in 1986
- Essential to many applications - e.g. cars, trucks, tractors, industrial robots, ...
Imagine that your car is like a human body:
The Controller Area Network (CAN bus) is the nervous system, enabling communication between all parts of the body.
Similarly, ‘nodes’ - or electronic control units (ECU) - are connected via the CAN bus, which acts as a central networking system.
So what's an ECU?
In an automotive CAN bus system, ECUs can e.g. be the engine control unit, airbags - or the audio system.
A modern car can have up to 70 ECUs.
This is where the CAN standard comes in handy:
The CAN bus protocol allows ECUs to communicate with each other without complex dedicated wiring in between. In turn this allows for several features to be added via software alone, e.g. electronic gearbox control.
Indeed, that is the primary purpose of the Controller Area Network:
To allow any ECU to communicate with the entire system without causing an overload to the controller computer.
But that's not all: Below are 5 core reasons why CAN bus is so popular:
5 Critical Advantages of CAN Bus Communication
- Low cost: ECUs communicate via a single CAN interface, i.e. not direct analogue signal lines, reducing errors, weight, costs
- Centralized: The CAN bus system allows for central error diagnosis and configuration across all ECUs
- Robust: The system is robust towards failure of subsystems and electromagnetic interference, making it ideal for e.g. vehicles
- Efficient: CAN messages are prioritized via IDs so that the highest priority IDs are non-interrupted (key in e.g. vehicles)
- Flexible: Each ECU contains a chip for receiving all transmitted messages, decide relevance and act accordingly - this allows easy modification and inclusion of additional nodes (e.g. CAN bus data loggers) - cf. below figure
The CAN bus history in short ...
- Pre CAN: Car ECUs relied on complex point-to-point wiring
- 1986: Bosch developed the CAN bus protocol as a solution
- 1991: Bosch published CAN 2.0 (CAN 2.0A: 11 bit, 2.0B: 29 bit)
- 1993: CAN is adopted as international standard (ISO 11898)
- 2012: Bosch released the CAN FD 1.0 (flexible data rate)
Today, the CAN protocol is standard in practically all vehicles (cars, trucks, buses, tractors, ...) - as well as ships, planes, EV batteries, industrial machinery and more.
Further, more exotic cases include drones, radar systems, submarines or even prosthetic limbs.
... And The Future of CAN Bus
Looking ahead, the CAN bus protocol will stay relevant - though it will be impacted by major trends:
The rise in connected vehicles & cloud computing will lead to a rapid growth in telematics and WiFi CAN bus analyzers.
But perhaps more fundamentally, the push for increased vehicle functionality may require changes to the core CAN technology.
The Rise of CAN FD
Increased vehicle functionality means a rapid increase in the data load of the vehicle CAN bus.
To support this demand, CAN FD (Flexible Data Rate) will be a critical enabler.
Basically, today's CAN bus systems face a major roadblock: The speed limit of 1 Mbit/s.
This level of speed is simply proving insufficient for handling the future CAN bus data loads.
CAN FD provides two key solutions:
- It enables data transmission up to 8 Mbit/s - far beyond the 1 Mbit/s of regular CAN
- Further, it allows data packets of 64 bytes (instead of 8 bytes), reducing packet complexity
There is no doubt that CAN FD will play a major role going forward:
CAN Message - And How Do You Log & Convert It?
A CAN message is comprised of 8 components - and can easily be logged with a CAN data logger or interface
To understand how the CAN bus system works, let's break down the messages sent over the network.
The figure below shows a simplified picture of a CAN message with extended 29 bits identifier (i.e. CAN 2.0B), which is the format used in e.g. the J1939 protocol for trucks and buses. The 11-bit identifier (CAN 2.0A) messages look similar, but with shorter CAN IDs.
SOF: The Start of Frame is a 'dominant 0' to tell the other ECUs that a message is coming
CAN-ID: Contains the message identifier - lower values have higher priority (e.g. RPM, wheel speed, ...)
RTR: The Remote Transmission Request allows ECUs to "request" messages from other ECUs
Control: Informs the length of the Data in bytes (0 to 8 bytes)
Data: Contains the actual data values, which need to be "scaled" or converted to be readable and ready for analysis
CRC: The Cyclic Redundancy Check is used to ensure data integrity
ACK: The ACK slot indicates if the CRC process is OK
EOF: Marks the end of the CAN message
How to Log CAN Bus Data
Of the 8 CAN elements, only 3 are relevant in most CAN logging scenarios:
The CAN ID, the Control and the Data field.
To log this CAN data, you'll need a CAN bus data logger. This lets you "listen" to broadcasted raw CAN messages and record these to an SD card for further analysis.
In your car, for example, you'll find an OBD2 connector under the steering wheel - connecting your logger to this lets you record raw CAN data incl. OBD2 data.
Check this ~1 min explainer to see how a CAN logger works
Below is an example raw OBD2 log file from a car (Audi A4), logged using the CL2000.
Note that the car data sample contains vehicle speed data (OBD2 PID 0D) - as well as proprietary raw CAN protocol messages:
Get started with CAN logging now
To truly learn about CAN bus, the only way is to record real CAN data yourself.
The CLX000 CAN logger lets you record raw CAN data from any vehicle. Simply connect it to e.g. your car or truck and record weeks of data to the 8GB SD card.
Further, with CANvas, you can easily decode the data using our built-in OBD2 database or *.DBC files (more on this below).
How to Decode CAN Bus Data
If you check out the raw CAN bus data sample above, you'll probably notice something:
Raw CAN bus data makes no sense!
That's because you need to decode the data into scaled engineering values - AKA human-readable form
To do this, you'll need to know a couple of things:
For each ID (e.g. "34d" in HEX in the above sample), you'll need to know what parameters (or CAN signals) are included.
For example, in the 64 bits of data in 34d there may be CAN data from 3 parameters, each with a specific bit start and bit length.
For each CAN signal, you then take the decimal value of the data bits and "scale" this (typically as below):
[Scaled Data Value] = [Offset] + [Scale] x [Raw Decimal Data Value]
In other words, you'll need for each parameter the offset and scale values.
How do you find this CAN decoding information?
Most often, these "conversion rules" are proprietary and not easily available. So, if you e.g. want to convert raw CAN protocol data from your car, you'd need to reverse engineer the CAN bus data - which is not always easy.
However, in some cases standardized decoding databases exist:
Example: J1939 DBC Files (Heavy Duty)
In some cases, conversion rules are standard across manufacturers - e.g. in the J1939 protocol for heavy-duty.
This means that you can use the J1939 parameter conversion rules on practically any heavy-duty vehicle to convert a large share of your data. To make this practical, you'll need a format for storing the conversion rules. Here, the *.DBC format is the industry standard - and is supported by most CAN bus software incl. CANvas.
We also offer a low cost J1939 DBC file, which you can purchase as a digital download. With this, you can get quickly from raw J1939 data to human-readable form:
What is the Link Between CAN bus and J1939, OBD-II & CANopen?
Many "higher layer protocols" are based on the CAN bus protocol - e.g. J1939, OBD2 and CANopen
These allow more complex communication in e.g. trucks, car diagnostics and industrial automation
The Controller Area Network provides the basis for communication - but not a lot more.
For example, the CAN standard does not specify how to handle messages larger than 8 bytes - or how to decode the raw data.
Therefore a set of standardized protocols exist to further define how data is communicated between ECUs of a given network.
Some of the most commonly encountered standards include SAE J1939, OBD-II and CANopen:
SAE J1939 is the standard in-vehicle network for trucks, buses and other heavy-duty vehicles. J1939 messages use the extended 29 bits CAN identifier. Further, J1939 data parameters (e.g. RPM, speed, ...) are identified by a suspect parameter number (SPN), which are in turn grouped in parameter group numbers (PGN) of SPNs.
For more details, see our J1939 intro or J1939 vehicle telematics intro.
On-board diagnostics (OBD) is a self-diagnostic and reporting capability that e.g. mechanics use to identify what is wrong with your car.
OBD2 specifies diagnostic trouble codes (DTCs) and real-time data (e.g. speed, RPM), which can be logged by e.g. an OBD2 data logger.
For details, see our OBD2 intro - or learn how to log your car's data in our OBD2 data logging intro.
CANopen is used widely in e.g. industrial automation applications. It builds on CAN in terms of the physical layer (i.e. lines used, voltages, ...) and the data link layer (i.e. utilizing a CAN frame message based protocol).
This means that a CAN bus data logger is also able to log data from CANopen applications. This can be useful in e.g. industrial machine diagnostics or to optimize production.
To learn more, check our CANopen intro or predictive maintenance article.
Where can I learn more?
You can go to our GUIDES section for more intros, guides & use cases.
Want to log data from your car, truck or other CAN application?
Then learn more about our CLX000 CAN logger below!
Liked this article? Please share!
RECOMMENDED FOR YOU