What Is CAN Bus?
The Controller Area Network (CAN) is used in e.g. automotives to allow communication between ECUs and sensors
- CAN is robust, low-cost message based protocol
- 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
- 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 increasingly complex point-to-point wiring
- 1986: Bosch developed the CAN bus protocol as a solution, releasing it at a SAE congress
- 1991: Bosch published CAN 2.0, incl. CAN 2.0A (11 bit) and CAN 2.0B (29 bit)
- 1993: CAN is adopted as international standard (ISO 11898)
- 2012: Bosch released the CAN FD 1.0, aka CAN with flexible data rate
Today, almost every new European car comes with a CAN bus system - and it is used broadly in trucks, buses, industry vehicles, ships, planes and industrial automation.
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 - and most likely even more so with the rise of e.g. cloud computing, Internet of Things (IoT) and autonomous vehicles. These trends will also boost the need for CAN bus decoders with WiFi / celluar connectivity - allowing wireless transfer of CAN bus data to e.g. cloud servers.
With 1.8 billion CAN bus interfaces sold in 2016, CAN is already a critical and fast-growing technology worldwide. But the increasing need for efficient, robust and low-cost intra-communication systems will undoubtedly give rise to massive growth going forward.
To enable this future CAN FD (Flexible Data Rate) will be a critical component.
Basically, today's CAN bus systems face a major roadblock: The speed limit of 1 Mbit/s.
With increasing complexity and requirements for data speed (more ECUs, data), this is a growing challenge.
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:
What is a 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.
The 8 Components of a CAN Bus Message
- 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
In short, the CAN bus message contains a lot of components!
However, only 3 are practically relevant in most data logging scenarios:
The CAN ID, the Control and the Data field.
To log this data, you'll need a CAN bus data logger or interface.
Such a device will act as a "node" on the CAN bus and will be able to read all broadcasted CAN messages e.g. onto an SD card.
Note: Applications require different ways of connecting the CAN logger.
For example, in a car you'll find an OBD2 connector under the steering wheel - connecting your logger to this will allow you to record the raw CAN bus data.
Check this ~1 min explainer video for the CLX000 to see how a CAN data logger & interface works
Indeed, below is an example log file from a car using the CLX000:
How to Convert Raw CAN Bus Data to Human-Readable Form
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 convert 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 might be CAN data from 3 different parameters, each with a specific bit start and bit length.
Again, for each of these CAN signals, you need to know how to decode the CAN data.
This typically involves a linear combination of the decimal value of the data, i.e.:
[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 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.
In some cases, most parameters are standardized across manufacturers - e.g. in SAE J1939 for heavy-duty vehicles
Finally, you'll also need a simple way to store the rules and convert the data.
One popular CAN database file format is *.DBC - which can be used by most CAN bus software, incl. CANvas.
What is the Link Between CAN bus and J1939, OBD-II & CANopen?
Many "higher layer protocols" are based on CAN bus - e.g. J1939, OBD2 and CANopen
These allow more complex communication in e.g. trucks, car diagnostics and industrial automation
CAN 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: