CAN Bus Explained – A Simple Intro (2018)

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! Enjoy! 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 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 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 priority as well
as functional address (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 checks 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 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 information, 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 CAN logger CLX000, 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 CAN logger CLX000 is able to log data from CANopen applications, though the method
for ex post data conversion will vary depending on the specific application. Our INTEL 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 CAN logger CLX000 series of
CAN bus data loggers here.

About the Author: Michael Flood

Leave a Reply

Your email address will not be published. Required fields are marked *