Struggling to find an intro to CAN bus written in layman's terms? So were we!
Therefore we've launched a series of simple CAN intro articles - written by one of our non-engineers to make sure it stays simple!
Below we ensure that the basics of CAN bus are explained simply - enjoy!
Note: You can also check out our video above with a smooth voice over by Samuel Fleming!
What’s CAN bus all about?
Imagine that your car is like a human body:
The Controller Area Network system (CAN bus) is the nervous system, facilitating 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.
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 as it 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 CAN:
To allow any ECU to communicate with the entire system without causing an overload to the controller computer.
But why is CAN so popular? Five key reasons:
- 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 message are prioritized based on IDs so that the highest priority IDs are non-interrupted - critical in e.g. vehicles
- Flexible: Each ECU contains a chip allowing it to receive all transmitted messages, decide relevance and act accordingly - this allows easy modification and inclusion of additional nodes such as CAN bus data loggers (cf. below figure for illustration)
The CAN bus history in short
- Pre CAN: Car ECUs relied on increasingly complex point-to-point wiring
- 1986: Bosch developed the CAN 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. Looking ahead, the CAN bus system will stay relevant - and most likely even more so with the rise of e.g. cloud computing, Internet of Things (IoT) and autonomous vehicles.
What does a CAN message look like?
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 key parts of a CAN message are as follow:
- 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
That's a lot! But only 3 are practically relevant in most data logging scenarios:
The CAN ID, the Control and the Data field.
This is also why you typically only see these in CAN bus data output - see e.g. an example log file here.
And how do protocols like J1939, OBD-II and CANopen fit in?
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: