How to get started with CAN-bus

In this article we will outline what CAN-bus is, types of application and what you need to get started with a CAN-bus project.

What is CAN-bus?

CAN stands for Controller Area Network and it is a serial communications bus for bidirectional transmission of data for control systems. Connections between control units and input and output devices are typically made using a two-wire, twisted-pair cable and data rates of up to 1 Mb/s are possible, depending on bus length. CAN-bus is characterised by guaranteed latency and excellent error detection.

Originally developed for use in automotive applications to simplify and reduce wiring, the protocol has proven to be versatile and suitable for a variety of industries. Robert Bosch GmbH started developing CAN in the 1980s and Mercedes Benz was the first to adopt the protocol for a production vehicle in 1991. The protocol name is often written as CAN, CAN-bus, CAN bus and CANbus, but we use CAN-bus for consistency.

What types of application is CAN-bus used for?

Within an automotive application, which may be a car, truck or other vehicle, CAN-bus is typically used to connect electronic control units (ECUs) with almost any electrical or electronic device. This includes driving instruments, anti-lock braking system (ABS), engine- and transmission-related sensors and actuators components, electric windows, air conditioning, etc.

Because road vehicles are electrically noisy environments, CAN-bus has to be a robust and reliable communications protocol, while still achieving high performance. These characteristics, together with the low cost of the hardware, also make the protocol attractive for other applications, including off-highway vehicles, marine, medical, industrial automation and building information management (BIM) systems.


The latest version of the specification published by Bosch is CAN 2.0. This has two parts, with part A covering the standard format with an 11-bit identifier and part B covering the extended format with a 29-bit identifier. Because of this, a CAN device using 11-bit identifiers is commonly referred to as CAN 2.0A and a device using 29-bit identifiers is known as CAN 2.0B. The CAN standards and other specifications are freely available from Bosch.

In 2012, Bosch published an additional specification, CAN FD 1.0 for CAN with a flexible data-rate. This uses a different frame format that allows a different data length as well as optionally switching to a faster bit rate after arbitration (message prioritisation). CAN FD is compatible with existing CAN 2.0 networks so CAN FD and CAN 2.0 devices can coexist on the same network.

Following the initial work by Bosch, the International Organization for Standardization (ISO) published ISO 11898 in 1993. This was later restructured and it is currently a four-part standard:

  • ISO 11898-1:2015 Road vehicles - Controller area network (CAN) - Part 1: Data link layer and physical signalling
  • ISO 11898-2:2016 Road vehicles - Controller area network (CAN) - Part 2: High-speed medium access unit
  • ISO 11898-3:2006 Road vehicles - Controller area network (CAN) - Part 3: Low-speed, fault-tolerant, medium-dependent interface
  • ISO 11898-4:2004 Road vehicles - Controller area network (CAN) - Part 4: Time-triggered communication

This standard has also been adopted in some countries as a national standard so that, for example, in the UK it is published by BSI as a four-part British Standard BS ISO 11898.

Another two-part international standard relates to testing of CAN systems:

  • ISO 16845-1:2016 Road vehicles - Controller area network (CAN) conformance test plan - Part 1: Data link layer and physical signalling
  • ISO 16845-2:2014 Road vehicles - Controller area network (CAN) conformance test plan - Part 2: High-speed medium access unit with selective wake-up functionality

ISO 11898 and the Bosch specifications do not consider application layer protocols so, for example, automotive manufacturers tend to have their own standards and others have been developed for particular industries. Commonly encountered CAN-based higher-layer protocols include:

  • CANopen for industrial automation
  • DeviceNet for industrial automation
  • ISO Bus (ISOBUS), ISO 11783, for agricultural and forestry machinery (based on SAE J1939)
  • ISO-TP (Transport Layer), ISO 15765-2, for sending data packets and diagnostic messages over CAN-bus
  • SAE J1939 for buses and trucks originally, but now adopted more widely for diesel engine applications
  • NMEA 2000 (NMEA2k or N2K), IEC 61162-3, for marine sensors and displays in boats and ships (based on SAE J1939)

What types of CAN-bus are available?

As we have seen above, CAN-bus does not come in just one ‘flavour’ – there are many to choose from, so it is important to select the right one to suit your application. Here is a summary of the main versions and options:

CAN 2.0A – This type of CAN is sometimes called Classic CAN and uses 11-bit identifiers (referred to as ‘standard frame’). Compared with CAN 2.0B, CAN 2.0A has capacity for greater message throughout and shorter latency times. CAN 2.0A chips also cost less than CAN 2.0B chips.

CAN 2.0B – This is the ‘extended frame’ CAN protocol that uses 29-bit identifiers. Compared with CAN 2.0A, CAN 2.0B enables each message to contain more information but the downside is that more bus bandwidth is required.

CAN FD – As mentioned earlier, this is the version of CAN with a flexible data-rate. It uses a different frame format that allows a different data length as well as optionally switching to a faster bit rate after arbitration. By minimising latency, CAN FD brings CAN-bus closer to being a ‘real time’ protocol; data can be transmitted up to 30 times faster than with classic CAN-bus. In addition, CAN FD holds a maximum of 64 bytes of data per frame whereas classic CAN-bus only holds 8 bytes per frame. For CAN FD to operate reliably at high speeds, line parasitic capacitances have to be reduced, so components on the line must all be suitable for use with CAN FD.

CANopen – Not quite the same as CAN 2.0A, CAN 2.0B and CAN FD, CANopen is a communication protocol and device profile specification for embedded systems used in industrial automation and similar applications. Standards and specifications are published by the organisation CAN in Automation (CiA); these cover an addressing scheme, communication protocols and an application layer defined by a device profile. Note that the lower level protocol implementing the data link and physical layers is usually CAN-bus, but the CANopen device profile can also be implemented by devices using other means of communication such as Ethernet Powerlink and EtherCAT.


CAN-bus is a multi-master serial bus so microcontrollers and devices can communicate without a host computer. Each node on the network can be a microcontroller, embedded computer, I/O device or gateway that enables networked devices to interact with something else (for example, a computer or a non-CAN-compatible I/O device, typically via an Ethernet or USB connection).

Nodes are connected using shielded two-wire, twisted-pair cabling (120Ω nominal).

High-speed CAN networks (ISO 11898-2) use a linear bus terminated at each end with 120Ω resistors. In contrast, low-speed (fault-tolerant) networks (ISO 11898-3) feature a linear bus, star bus or multiple star buses connected by a linear bus. Each node is terminated by a fraction of the overall resistance, which should be approximately 100Ω but not less than 100Ω.

Each node on the network comprises:

  • CAN transceiver for transmitting and receiving data streams
  • microcontroller (central processing unit, microprocessor or host processor) for interpreting messages and determining what messages are to be sent
  • CAN controller (often integral with the microcontroller) for receiving and assembling data bits from the network and for transmitting data bits after receiving messages from the microcontroller

Higher-level control devices and I/O devices are connected to the microcontroller.


The CAN-bus protocol can be considered as a series of abstraction layers:

  • application layer
  • object layer
  • transfer layer
  • physical layer

The application layer is not covered by the CAN standards but, instead, is addressed by other standards and specifications, often industry-orientated (eg SAE J1939, CANopen and DeviceNet). The other layers are outlined below.

Object layer – deals with message filtering and message and status handling.

Transfer layer – this moves messages between the physical layer and the object layer. The transfer layer lies at the heart of the CAN-bus protocol and performs a wide variety of tasks, including bit timing, synchronisation, message timing, arbitration, acknowledgement, error handling, transfer rate and timing, and information routing.

Physical layer – whereas other layers exist in software, the physical layer predominantly concerns electrical and mechanical aspects. ISO 11898-2 specifies the voltage, current and number of conductors, but not the connector type, colours, labels and pin-outs. These therefore vary between different applications, even to the extent that some users (eg in the automotive industry) have custom connectors that incorporate CAN-bus pins alongside others for different functions. However, many CAN-bus applications utilise standard 9-pin D-sub connectors.


CAN-bus has two frame formats:

  • Standard (base) frame format (CAN 2.0A,) supporting an 11-bit identifier
  • Extended frame format (CAN 2.0B), supporting a 29-bit identifier comprising an 11-bit identifier plus an 18-bit extension

A base frame message is recognised from the dominant IDE bit, while an extended base frame has a recessive IDE bit. CAN-bus controllers that support the extended frame format can also send and receive messages in base frame format.

In addition to the two different frame formats, there are four types of CAN-bus frame:

  • Data frames contain node data for transmission
  • Remote frames request the transmission of a specific frame identifier
  • Error frames are transmitted by nodes detecting errors
  • Overload frames inject a delay between data or remote frames

Starting a CAN-bus project

The bare minimum for starting a CAN-bus project is a CAN-bus controller, compatible cabling and one or more CAN-enabled I/O devices. CAN-bus controllers can typically be programmed in C, but Matlab and Labview are popular alternatives, and CODESYS is an option for some controllers. Various libraries – for example, for CANopen, J1939 and error handling – can simplify programming and save time. The programming software will usually be run on a PC that can be connected to the controller for uploading the program.

Pros and cons of CAN-bus

First of all, the pros:

  • CAN-bus systems allow data transmission at up to 1 Mb/s (or >2 Mb/s for CAN FD).
  • As a distributed system, it reduces wiring, cost and complexity, and enhances overall system capabilities and performance.
  • Easy integration – because there are so many CAN chip manufacturers who provide the data and physical layer, all the software developer needs to do is to write the code for the application level.
  • Robust EMC protection – CAN-bus operates in difficult electrical environments and ensures noise-free transmission.
  • Traffic congestion is eliminated because the messages are transmitted based on their priority, so the entire network can meet the timing constraints.
  • Error-free transmission because each node can check for errors during the transmission of the message and send the error frame.

However, CAN-bus is not ideal for every application:

  • In most cases a maximum of 64 nodes can be supported.
  • Networks can only operate over distances of up to 40m with data rates of 1 MB/s (5 km is possible but data rates are reduced to 10 kB/s).
  • There can sometimes be undesirable interactions between nodes, and the topology must be designed with care to minimise stubs.

Common myths and misconceptions about CAN-bus

Can-bus is often viewed as a low-cost, widely used and easy-to-implement protocol but that does not mean it is as simple as plug-and-play. It is definitely true that care must be taken when designing and implementing a CAN-bus system, otherwise problems can arise. It is vital that OEMs understand the implications of ISO 11898 on their wiring designs.

CAN is fault tolerant, and more so than most other communications protocols, but there are limits to the fault tolerance. If the operating environment or the wiring is electrically very noisy, then the CAN-bus will shut itself down due to a build-up of error frames. Just because CAN-bus is fault-tolerant, it does not mean that it can cope with a multitude of sins on the physical side. This is particularly relevant with electric vehicles.

Real-world CAN-bus systems

Control Technologies UK is a CAN-bus specialist with many years of real-world experience with control systems, helping companies from multiple industries to leverage greater functionality, efficiency and cost savings. Whether you are looking for real-time distributed control, remote data retrieval and analytics, intuitive visualisation or need support to improve the performance of an existing CAN-bus system, our team is available to provide advice and engineering. We work closely with a network of leading manufacturers and technology partners, ensuring that customers benefit from the most relevant solution to their CAN-bus challenges. Overall, we offer the most complete end-to-end service, extending your engineering capabilities without extending your overheads.

Contact us to discuss your CAN-bus and control system requirements.