CAN bus


A controller area network is a vehicle bus standard designed to enable efficient communication primarily between electronic control units. Originally developed to reduce the complexity and cost of electrical wiring in automobiles through multiplexing, the CAN bus protocol has since been adopted in various other contexts, such as 3D printing. This broadcast-based, message-oriented protocol ensures data integrity and prioritization through a process called arbitration, allowing the highest priority device to continue transmitting if multiple devices attempt to send data simultaneously, while others back off. Its reliability is enhanced by differential signaling, which mitigates electrical noise. Common versions of the CAN protocol include CAN 2.0, CAN FD, and CAN XL which vary in their data rate capabilities and maximum data payload sizes.

History

Development of the CAN bus started in 1983 at Robert Bosch GmbH. The protocol was officially released in 1986 at the Society of Automotive Engineers conference in Detroit, Michigan. The first CAN controller chips were introduced by Intel in 1987, and shortly thereafter by Philips. Released in 1991, the Mercedes-Benz W140 was the first production vehicle to feature a CAN-based multiplex wiring system.
Bosch published several versions of the CAN specification. The latest is CAN 2.0, published in 1991. This specification has two parts. Part A is for the standard format with an 11-bit identifier, and part B is for the extended format with a 29-bit identifier. A CAN device that uses 11-bit identifiers is commonly called CAN 2.0A, and a CAN device that uses 29-bit identifiers is commonly called CAN 2.0B. These standards are freely available from Bosch along with other specifications and white papers.
In 1993, the International Organization for Standardization released CAN standard ISO 11898, which was later restructured into two parts: ISO 11898-1 which covers the data link layer, and ISO 11898-2 which covers the CAN physical layer for high-speed CAN. ISO 11898-3 was released later and covers the CAN physical layer for low-speed, fault-tolerant CAN. The physical layer standards ISO 11898-2 and ISO 11898-3 are not part of the Bosch CAN 2.0 specification.
In 2012, Bosch released CAN FD 1.0, or CAN with Flexible Data-Rate. This specification uses a different frame format that allows a different data length as well as optionally switching to a faster bit rate after the arbitration is decided. CAN FD is compatible with existing CAN 2.0 networks so new CAN FD devices can coexist on the same network with existing CAN devices, using the same CAN 2.0 communication parameters., Bosch was active in extending CAN standards.
The CAN bus is one of five protocols used in the on-board diagnostics -II vehicle diagnostics standard. The OBD-II standard has been mandatory for all cars and light trucks sold in the United States since model year 1996. The EOBD standard has been mandatory for all petrol vehicles sold in the European Union since 2001 and all diesel vehicles since 2004.

Applications

Automotive

The modern automobile may have as many as 70 electronic control units for various subsystems. Usually the biggest processor is the engine control unit. Others are used for autonomous driving, advanced driver assistance system, transmission, airbags, antilock braking/ABS, cruise control, electric power steering, audio systems, power windows, doors, mirror adjustment, battery and recharging systems for hybrid/electric cars, etc. Some of these form independent subsystems, but communication among others is essential. A subsystem may need to control actuators or receive feedback from sensors. The CAN standard was devised to fill this need. One key advantage is that interconnection between different vehicle systems can allow a wide range of safety, economy and convenience features to be implemented using software alone - functionality which would add cost and complexity if such features were hard wired using traditional automotive electrics. Examples include:
  • Auto start/stop: Various sensor inputs from around the vehicle are collated via the CAN bus to determine whether the engine can be shut down when stationary for improved fuel economy and emissions.
  • Electric park brakes: The hill hold functionality takes input from the vehicle's tilt sensor and the road speed sensors via the CAN bus to determine if the vehicle is stopped on an incline. Similarly, inputs from seat belt sensors are fed from the CAN bus to determine if the seat belts are fastened, so that the parking brake will automatically release upon moving off.
  • Parking assist systems: when the driver engages reverse gear, the transmission control unit can send a signal via the CAN bus to activate both the parking sensor system and the door control module for the passenger side door mirror to tilt downward to show the position of the curb. The CAN bus also takes inputs from the rain sensor to trigger the rear windscreen wiper when reversing.
  • Auto lane assist/collision avoidance systems: The inputs from the parking sensors are also used by the CAN bus to feed outside proximity data to driver assist systems such as Lane Departure warning, and more recently, these signals travel through the CAN bus to actuate brake by wire in active collision avoidance systems.
  • Auto brake wiping: Input is taken from the rain sensor via the CAN bus to the ABS module to initiate an imperceptible application of the brakes while driving to clear moisture from the brake rotors. Some high-performance Audi and BMW models incorporate this feature.
  • Sensors can be placed at the most suitable place, and their data used by several ECUs. For example, outdoor temperature sensors can be placed in the outside mirrors, avoiding heating by the engine, and data used by the engine, the climate control, and the driver display.
In recent years, the LIN bus standard has been introduced to complement CAN for non-critical subsystems such as air-conditioning and infotainment, where data transmission speed and reliability are less critical.

3D Printing

CAN bus is often used to connect 3D printer mainboards to expansion boards due to its high electrical noise tolerance, especially from ground noise generated by stepper motors, commonly used in 3D printers and other CNC applications. The CAN FD variant is used by many, such as the Duet3D controller family, as it has higher bandwidth needed to support the high command rates of 3D printing.

Other

  • The CAN bus protocol has been used on the Shimano DI2 electronic gear shift system for road bicycles since 2009, and is also used by the Ansmann and BionX systems in their direct drive motor.
  • The CAN bus is also used as a fieldbus in general automation environments, primarily due to the low cost of some CAN controllers and processors.
  • Manufacturers including NISMO aim to use CAN bus data to recreate real-life racing laps in the videogame Gran Turismo 6 using the game's GPS Data Logger function, which would then allow players to race against real laps.
  • Johns Hopkins University's Applied Physics Laboratory's Modular Prosthetic Limb uses a local CAN bus to facilitate communication between servos and microcontrollers in the prosthetic arm.
  • Teams in the FIRST Robotics Competition widely use CAN bus to communicate between the roboRIO and other robot control modules.
  • The CueScript teleprompter range uses CAN bus protocol over coaxial cable, to connect its CSSC – Desktop Scroll Control to the main unit
  • The CAN bus protocol is widely implemented due to its fault tolerance in electrically noisy environments such as model railroad sensor feedback systems by major commercial Digital Command Control system manufacturers and various open-source digital model railroad control projects.
  • Shearwater Research have implemented the protocol as DiveCAN to use integrating their dive computers into diving rebreathers from various manufacturers.

    Versions

CAN 2.0 (Classical CAN)

Due to its legacy, CAN 2.0 is the most widely used protocol with a maximum payload size of eight bytes and a typical baud rate of 500 kbit/s. Classical CAN, which includes CAN 2.0A and CAN 2.0B, primarily differs in identifier field lengths: CAN 2.0A uses an 11-bit identifier, while CAN 2.0B employs a 29-bit identifier. The longer identifier in CAN 2.0B allows for a greater number of unique message identifiers, which is beneficial in complex systems with many nodes and data types. However, this increase in unique message identifiers also increases frame length, which in turn reduces the maximum data rate. Additionally, the extended identifier provides finer control over message prioritization due to more available identifier values. This, however, may introduce compatibility issues; CAN 2.0A devices can generally communicate with CAN 2.0B devices, but not vice versa, due to potential errors in handling longer identifiers. High-speed CAN 2.0 supports bit rates from 40 kbit/s to 1 Mbit/s and is the basis for higher-layer protocols. In contrast, low-speed CAN 2.0 supports bit rates from 40 kbit/s to 125 kbit/s and offers fault tolerance by allowing communication to continue despite a fault in one of the two wires, with each node maintaining its own termination.

[CAN FD]

CAN FD, standardized as ISO 11898-1, was developed by Bosch and released in 2012 to meet the need for increased data transfer in modern high-performance vehicles. It offers variable data rates during the transmission of a single frame, allowing the arbitration phase to occur at a lower data rate for robust communication, while the data payload is transmitted at a higher data rate to improve throughput, which is particularly useful in electrically noisy environments for better noise immunity. CAN FD also introduces a flexible data field size, increasing the maximum size from 8 bytes to 64 bytes. This flexibility allows for more efficient data transmission by reducing the number of frames needed for large data transfers, which is beneficial for applications like high-resolution sensor data or software updates.
CAN FD maintains backward compatibility with CAN 2.0 devices by using the same frame format as CAN 2.0B, with the addition of a new control field to indicate whether the frame is a CAN FD frame or a standard CAN 2.0 frame. This allows CAN FD devices to coexist with CAN 2.0 devices on the same bus, while higher data rates and larger data payloads are available only when communicating with other CAN FD devices.