Skip to Content

Controller Area Network (CAN) Overview

Last modified by Microchip on 2023/11/09 08:54
Contents

Controller Area Network (CAN) is a very reliable, multi-drop asynchronous serial network technology that was originally designed for automotive communications but has also become a popular bus for industrial automation, as well as other applications.

The typical medium is a twisted pair of wires and the maximum network length depends on the network speed chosen (longer distances are achievable at lower speeds), for example:

  • 40m @ 1 Mbps
  • 500m @ 125 kbps

twisted pair

There are a variety of CAN node configuration possibilities, however, all nodes contain a CAN transceiver, a CAN controller, and an application controller (MCU) as shown:

Microchip offers a variety of CAN transceivers, CAN controllers, and MCUs with built-in CAN controllers to enable these common CAN node configurations.

CAN applications

CAN Applications

CAN's main advantages as a serial bus lie in the reduction of expensive wiring, as well as an increased performance by enabling a distributed processing system. CAN has been used in the following applications:

  • Passenger Cars
  • Building Automation
  • Trucks and Buses
  • Industrial Machine Control
  • Lifts and Escalators
  • Trains
  • Maritime Electronic Systems
  • Aircraft & Aerospace Electronics

CAN vs CAN FD signaling

CAN Variants

There was what is now referred to as the "Classical" CAN data link layer protocol, originally developed by Bosch as CAN 2.0A/B. This was standardized in the ISO11898 series standards beginning in 1993.

In order to address bandwidth limitations as well as end-of-line manufacturing delays in programming Engine Control Units (ECUs) in cars, Bosch in 2012 updated the protocol to what is now known as CAN with Flexible Data-Rate (CAN FD).

Both data link layer protocols are now internationally standardized in ISO11898-1:2015.

CAN FD data frames are transmitted with two different bit rates. The arbitration phase is transmitted at up to 1 Mbps (compatible with Classical CAN), however in the data phase, since only one node is transmitting, the bit rate is limited only by the transceiver characteristics and approaches 8 Mbps. Additionally, CAN FD extends the maximum number of data bytes in the payload from 8 to 64 bytes as shown:

CAN FD controllers are able to operate in Classic CAN systems, while Classic CAN controllers will generate errors in a CAN FD system.
Kvaser published a useful guide outlining the impact to various stakeholders of switching to a CAN FD design.

Network Basics

CAN is a multi-master network, so each node may send its data at any time. Collisions get resolved by priority, through an automatic arbitration process occurring at the physical layer. Messages contain an 11/29-bit message identifier. The message with the lowest message ID value wins the arbitration process and gets through.

​Custom application layer software or other Higher-Layer Protocols (HLPs) (such as J1939, CANopen, etc) must ensure the uniqueness of the CAN message IDs by assigning/reserving certain IDs for certain functions/purposes.

Messages are broadcast to all nodes, however, the multi-casting capability is built into the system by hardware message ID filters which are available in the CAN controller at each node.

A Cyclic Redundancy Checksum (CRC) is included in each packet and is checked by CAN hardware on each node of the bus. If a single node reports a CRC error, all other nodes discard the message and it automatically gets re-transmitted.

Signaling basics

Signaling Basics

CAN signaling differs from other communications protocols, in that a logic 0 level is referred to as the dominant bit and is encoded as a differential signal on the bus of ~2 volts, while a logic 1 level is referred to as the recessive bit and is encoded as a differential signal of ~0 volts, as shown:

Higher Layer Protocol stacks

Higher Layer Protocols (HLPs)

Many network protocols are described using the seven-layer Open System Interconnection (OSI) model, as depicted here:

The CAN protocol (ISO11898) defines the data link layer and part of the physical layer in the OSI model. The remaining physical layer (and all of the higher layers) are not defined by the CAN specification. These other layers can either be defined by the system designer (a "homegrown" stack), or implemented using existing non-proprietary HLPs such as CANopen or DeviceNet.

What Can HLPs Provide?

An HLP can provide additional functionality on top of the basic CAN protocol:

  • Provides flow control and the ability to transfer data units larger than 8 bytes.
  • Coordinates installations of additional nodes.
  • Network Management (Startup behavior, Sleep behavior, Status reporting within the CAN network system)
  • Can guarantee that the information reached the correct node.
  • Can define how to distribute message identifiers among the different nodes in a system.
  • Can define how to translate the contents of the data frames.
  • Development Environment and Tool support.