A Brief Introduction to Controller Area Network

Controller Area Network (CAN) is a serial network technology that was originally designed for the automotive industry, especially for European cars, but has also become a popular bus in industrial automation as well as other applications. The CAN bus is primarily used in embedded systems, and as its name implies, is a network technology that provides fast communication among microcontrollers up to real-time requirements, eliminating the need for the much more expensive and complex technology of a Dual-Ported RAM.

Introduction

CAN is a two-wire, half duplex, high-speed network system, that is far superior to conventional serial technologies such as RS232 in regards to functionality and reliability and yet CAN implementations are more cost effective. 

While, for instance, TCP/IP is designed for the transport of large data amounts, CAN is designed for real-time requirements and with its 1 MBit/sec baud rate can easily beat a 100 MBit/sec TCP/IP connection when it comes to short reaction times, timely error detection, quick error recovery and error repair.

CAN networks can be used as an embedded communication system for microcontrollers as well as an open communication system for intelligent devices. Some users, for example in the field of medical engineering, opted for CAN because they have to meet particularly stringent safety requirements.

Similar requirements had to be considered by manufacturers of other equipment with very high safety or reliability requirements (e.g. robots, lifts and transportation systems).

The greatest advantage of Controller Area Network lies in the reduced amount of wiring combined with an ingenious prevention of message collision (meaning no data will be lost during message transmission).

Without CAN                          -                         With CAN

The following shows a need-to-know overview of CAN’s technical characteristics.

Controller Area Network

• Is a serial networking technology for embedded solutions.
• Needs only two wires named CAN_H and CAN_L.
• Operates at data rates of up to 1 Megabit per second.
• Supports a maximum of 8 bytes per message frame.
• Does not support node IDs, only message IDs. One application can support multiple message IDs.
• Supports message priority, i.e. the lower the message ID the higher its priority.
• Supports two message ID lengths, 11-bit (standard) and 29-bit (extended).
• Does not experience message collisions (as they can occur under other serial technologies).
• Is not demanding in terms of cable requirements. Twisted-pair wiring is sufficient.

CAN Interface Hardware

A great variety of microprocessor chips, such as the ARM Cortex-M3 processor, provide interfaces such as Ethernet, digital I/O, analog I/O, USB, UARTS, and, last but not least, Controller Area Network. However, that does not mean that you can use the chip “as is” and connect it to a network, sensors, etc. All of these interfaces require some kind of a “hardware driver.” In case of serial technologies such as RS232 or CAN, you will need the corresponding transceiver.

In the specific case of the CAN bus controller, we need a line driver (transceiver) to convert the controller’s TTL signal to the actual CAN level, which is a differential voltage. The use of differential voltage contributes to the vast reliability of CAN.

The next image compares both signals, TTL and differential voltage:

The actual signal status, recessive or dominant, is based on the differential voltage between CAN_H and CAN_L (2V during dominant bit time; 0V during recessive bit time).

CAN-Based Higher-Layer Protocols

Even though extremely effective in automobiles and small, embedded applications, CAN alone is not suitable for projects that require a minimum of network management and messages with more than eight data bytes.

As a consequence, higher-layer protocols (additional software on top of the CAN physical layer) such as CANopen for industrial automation and SAE J1939 for off-road vehicles were designed to provide an improved networking technology that support messages of unlimited length and allow network management, which includes the use of node IDs (CAN supports only message IDs where one node can manage multiple message IDs).

Ironically, however, it is very well foreseeable that the basic CAN technology will prevail over higher-layer protocols for the automation industry such as CANopen and DeviceNet, specifically due to its continued use in automobiles. These days, CANopen and DeviceNet are “dead” protocols when it comes to new developments. The only exception is SAE J1939, which is closely connected to the diesel engine technology and that includes, yet again, vehicles.

CANopen

• Is suited for embedded, industrial applications
• Was originally designed for motion control
• Was developed and is maintained by the CAN-in-Automation User Group

Like CAN, the CANopen standard is the responsibility of CiA (CAN-in-Automation). For further information, refer to their website at http://www.can-cia.org.

Note: I personally consider CANopen to be a fairly complex and tremendously over-bloated protocol with a disappointingly low bandwidth. Add to this that CANopen is rapidly losing its attraction for the automation industry due to the emergence of the more powerful Industrial Ethernet protocols, and now there are two reasons why I never attempted writing a CANopen stack.

SAE J1939

• Defines communication for vehicle networks (trucks, buses, agricultural equipment, etc.)
• Is a standard developed by the Society of Automotive Engineers (SAE)

The SAE J1939 Standards Collection can be found exclusively on the Web at http://www.sae.org.

The Society of Automotive Engineers (SAE) Truck and Bus Control and Communications Subcommittee has developed a family of standards concerning the design and use of devices that transmit electronic signals and control information among vehicle components. SAE J1939 and its companion documents have quickly become the accepted industry standard and the Controller Area Network (CAN) of choice for off-highway machines in applications such as construction, material handling, and forestry machines. 

Derivatives of SAE J1939 include:

• NMEA 2000 for marine applications
• ISOBUS (ISO 11783) for agricultural applications
• MilCAN for military applications

Note: In my book SAE J1939 ECU Programming & Vehicle Bus Simulation with the Arduino I introduce ARD1939, an SAE J1939 protocol stack for Arduino Uno and Mega 2560. The stack and the associated sample programs will also work on the Arduino Due.

DeviceNet

• Is suited for industrial applications (floor automation)
• Was developed by Allen Bradley/Rockwell
• Is maintained by Open DeviceNet Vendor Association (ODVA)

The DeviceNet Specification, consisting of two volumes: Volume One - Common Industrial Protocol (CIP) and Volume Three- DeviceNet Adaptation of CIP, is available only for ODVA (Open DeviceNet Vendor Association) members.

For further information, refer to http://www.odva.org.

---

A Comprehensible Guide to Controller Area Network by Wilfried Voss represents the most thoroughly researched and most complete work on CAN available in the marketplace.

Controller Area Network (CAN) is a serial network technology that was originally designed for the automotive industry, especially for European cars, but has also become a popular bus in industrial automation as well as other applications. The CAN bus is primarily used in embedded systems, and as its name implies, is a network technology that provides fast communication among microcontrollers up to real-time requirements, eliminating the need for the much more expensive and complex technology of a Dual-Ported RAM.

This book provides complete information on all CAN features and aspects combined with a high level of readability. => Read more...