CAN Bus Explained - A Simple Intro

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:

  1. Low cost: ECUs communicate via a single CAN interface, i.e. not direct analogue signal lines, reducing errors, weight, costs
  2. Centralized: The CAN bus system allows for central error diagnosis and configuration across all ECUs
  3. Robust: The system is robust towards failure of subsystems and electromagnetic interference, making it ideal for e.g. vehicles
  4. Efficient: CAN message are prioritized based on IDs so that the highest priority IDs are non-interrupted - critical in e.g. vehicles
  5. 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)

CAN-Bus-Transmit-Receive-Datamin

 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.

CANbus-Message-Frame-Structure-29-bit-Extended-Datamin

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:

SAE J1939: This is the standard in-vehicle network for buses, trucks and other heavy-duty vehicles. All J1939 messages rely on the extended 29 bits CAN identifier. Further, J1939 data parameters (e.g. RPM, vehicle speed, ...) are identified by a suspect parameter number (SPN), which are in turn grouped in parameter group numbers (PGN) containining 1+ SPNs. 

With this standardized structure, CAN messages from e.g. buses and trucks can be scaled and decoded into readable data using parameter tables from the J1939 standard. Further, several standards are derived from J1939, including e.g. the Fleet Management System (FMS), which is freely available and included in CANvas.

For more, see our simple intro to J1939 or our J1939 ID-to-PGN converter.

OBD-II: On-board diagnostics (OBD) is a self-diagnostic and reporting capability that e.g. mechanics use to identify what is wrong with your car. The OBD-II standard specifies a number of standardized diagnostic trouble codes (DTCs), which can be retrieved by a CAN logger or diagnostic tool from any vehicle.

But what makes OBD-II really interesting?

OBD-II supports data on many basic real-time parameters (e.g. vehicle speed, RPM, fuel consumption, ...). This means that OBD-II is also used for e.g. real-time vehicle telematics or post analysis using CAN data loggers. Applications include vehicle fleet management, fuel optimization, proactive vehicle diagnostics and more. 

To log OBD-II data, the CAN logger must “requests” the data by submitting pre-specified CAN frames with specific 'Parameter IDs' (PID) to the CAN bus. When using the CANLoggerX000, this can easily be configured in CANvas.

For the basics on OBD2, check out our simple intro to OBD2

Or, check our practical guides to logging OBD-II data or streaming it in Wireshark.

CANopen: 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). In practice this means that a data logger like the CANLoggerX000 is able to log data from CANopen applications, though the method for ex post data conversion will vary depending on the specific application.

 

Cool! Where can I learn more?

Our GUIDES page contains several intro articles, use cases and guides - let us know if you have more suggestions for the series!

Interested in our products?

Read more about our CANLoggerX000 series of CAN bus data loggers here.

 

 Liked this article? Please share!




RECOMMENDED FOR YOU



This site uses cookies to enhance your experience

Got it!