Controller Area Network (CAN)

Controller Area Network (CAN) started life in 1983 at Robert Bosch GmbH as a serial data bus standard for the interconnection of microcontrollers in vehicles. Although originally designed specifically for automotive applications, it is now also used in other applications. The protocol was officially released in 1986, and the first CAN controller chips, produced by Intel and Phillips, were available commercially in 1987. The CAN 2.0 specification was published by Bosch in 1991. The data link and physical layers of CAN for data rates of up to 125 kbps (described as "low-speed serial data communication" were defined in part two of the original ISO standard published in 1994 (ISO 11519). Part 1 of a later ISO standard published in 2003 (ISO 11898) covers the data link and physical layers of CAN, but for data rates of up to 1 Mbps. There are also a number of other related standards. The higher layer protocols used with CAN depend on the application. A number of microcontrollers (for example, Microchip Technology's PIC Microcontrollers) now have CAN support built-in.

A modern car will typically have in the order of fifty (and sometimes a lot more) electronic control units (ECUs) controlling various automotive sub-systems. The largest microprocessor unit in a car is usually the engine control unit (also, confusingly, commonly abbreviated to ECU). Other microprocessors control elements ranging from the transmission system and braking system, right down to cosmetic elements such in-car audio systems, and driving mirror adjustment. Some of these subsystems operate independently, but others need to communicate with each other and process and respond to data received from sensors. The CAN bus in a vehicle control system will typically connect the engine control unit with the transmission control system, for example. It is also highly suited to use as a fieldbus in general automation environments, and has become widely used for such applications, in part because of the low cost, small size and availability of many CAN controllers and processors. In automotive systems, they are an ideal alternative to expensive, cumbersome and unreliable wiring looms and connectors.

A CAN network interconnects control devices, sensors and actuators (collectively referred to here as nodes). Every node attached to a CAN bus can send and receive data, but not at the same time. A message consists primarily of an identifier that identifies the type and sender of the message, and up to eight bytes of actual data. The physical medium in a CAN network is a differential two-wire bus (usually either unshielded or shielded twisted pair), and the signaling scheme used is Non-Return to Zero (NRZ) with bit stuffing. Because CAN is essentially a broadcast network, messages will be received by all nodes. The messages do not reach the devices directly, but via each node?s host-processor and CAN Controller. These elements sit between the node itself and the data bus. Any node may transmit a message providing the bus is free. If two or more nodes transmit at the same time, the system of arbitration is simply to give priority based on message ID number. The message with the higher priority ID will overwrite all other messages, and any nodes responsible for the lower priority messages will back off and wait before retransmitting.

Each node will have a host-processor that interprets incoming messages and determines when it needs to send outgoing messages, sensors, actuators and control devices, which can be connected to the host-processor as required, and a CAN Controller which is implemented in hardware and has a synchronous clock. The CAN controller buffers incoming messages until they can be retrieved by the host-processor, generating an interrupt to let the host processor know that a message is waiting. The CAN Controller is also the buffer for outgoing messages, which it receives from the host-processor and then transmits via the bus. A transceiver handles message processing, and is usually integrated into the CAN Controller. The data rates possible are dependent on the length of the bus. Data rates of up to 1 Mbps are possible at network lengths below 40 metres. Decreasing the data rate to 125 kbps would allow a network length of up to 500 metres.

Transmission of messages in a CAN is based on the producer-consumer (broadcast) principle. A message transmitted by one node (the producer) is received by all other nodes (the consumers). Messages do not have a destination address, but a Message ID. Messages in the standard format have an 11-bit Message ID, enabling 2,048 different messages to be defined for any one system - more than sufficient for most applications. For applications that require a larger number of messages, an extended message format with a 29-bit Message ID may be used, allowing over five hundred million different messages to be defined. Only certain messages will apply to each node on the network, so a node receiving a message must apply acceptance filtering (usually implemented in hardware, and based on the Message ID). If the message received by a node is relevant to it, it will be processed, otherwise it will be ignored. CAN networks may be expanded without modification to existing hardware or software if the devices to be added are purely receivers, and if they only require messages that are already generated by the network.

Arbitration in CAN networks

The standard form of arbitration in a CAN network is Carrier Sense Multiple Access/Bitwise Arbitration (CSMA/BA). If two or more nodes start transmitting at the same time, arbitration is based on the priority level of the message ID, and allows the message whose ID has the highest priority to be delivered immediately, without delay. This makes CAN ideal for real-time, priority-based systems. Each node, when it starts to transmit its Message ID, will monitor the bus state and compare each bit received from the bus with the bit transmitted. If a dominant bit (0) is received when a recessive bit (1) has been transmitted, the node stops transmitting because another node has established priority. The concept is illustrated by the diagram below.

Arbitration is performed as the identifier field is transmitted, and is non-destructive. Each node transmits its 11-bit Message ID, starting with the highest-order bit (bit 10). Binary zero (0) is a dominant bit, and binary one (1) is a recessive bit. Because a dominant bit will overwrite a recessive bit on the bus, the state of the bus will always reflect the state of the message ID with the highest priority (i.e. the lowest number). As soon as a node sees a bit comparison that is unfavourable to itself, it will cease to participate in the arbitration process and wait until the bus is free again before attempting to retransmit its message. The message with the highest priority will thus continue to be transmitted without delay, and unimpeded. In the above illustration, Node 2 transmits bit 5 as a recessive bit (1), while the bus level read is dominant (0), so Node 2 will back off. Similarly, Node 1 will back off after transmitting bit 2 as a recessive bit, whereas the bus level remains dominant. Node 3 is then free to complete transmission of its message.

The Message ID for each system element is assigned by the system designer, and the arbitration method used ensures that the highest-priority messages will always be transmitted ahead of another message, should simultaneous transmissions occur. The bus is thus allocated on the basis of need. The only limiting factor is therefore the capacity of the bus itself. Outstanding transmission requests are dealt with in their order of priority, with minimum delay and maximum utilisation of the available bus capacity. In any system, some parameters will change more rapidly than others. In a motor vehicle, for example, the rpm of the engine will change far more rapidly than the temperature of the engine coolant. The more rapidly changing parameters are probably going to need more frequent monitoring, and for this reason will probably be given a higher priority.

CAN Frame Format

The general format of a CAN message frame is shown below.

Data is transmitted using Message Frames. The standard CAN protocol (version 2.0A), also known as Base Frame Format, uses an 11-bit Message ID. The extended CAN protocol (version 2.0B), also now known as Extended Frame Format, supports both 11-bit and 29-bit Message IDs. Most version 2.0A controllers are tolerant of extended format messages, but essentially ignore them. Version 2.0B controllers can send and receive messages in both formats.

The start of a message frame is signaled by a dominant start-of-frame bit, followed by the 11-bit Message ID and the Remote Transmission Request (RTR) bit, which is only set if the message is a data request frame (as opposed to a data frame). It should probably be noted here that, although nodes on a CAN network generally send data without being polled, a node may request the transmission of a specific message by another node in the system. The first two bits (r0 and r1) of the 6-bit control field specify the transmission format (i.e. standard or extended), while the last four bits form the Data Length Code (DLC), which indicates the number of bytes of data transmitted. The data field can contain from zero to eight bytes of data, and is followed by the 16-bit CRC field, containing a 15-bit cyclic redundancy check code which is used by the receiving node to detect errors, and a recessive delimiter bit.

The ACKnowledge field has two bits. The first is the ACK Slot which is transmitted as a recessive bit, but will be overwritten with a dominant bit by any node that successfully receives the transmitted message. The second bit is a recessive delimiter bit. The end-of-frame field consists of seven recessive bits, and signals that error-free transmission of the message has been completed. The end-of-frame field is followed by the intermission field consisting of three recessive bits, after which the bus may be considered to be free for use. Idle time on the bus may be of any length, including zero.

At a data rate of 1 Mbps, it is possible to send in the order of ten thousand standard format messages per second over a CAN network, assuming an average data length of four bytes. The number of messages that could be sent would come down to around seven thousand if all the messages contained the full eight bytes of data allowed. One of the major benefits of CAN is that, if several controllers require the same data from the same device, only one sensor is required rather than each controller being connected to a separate sensor. As mentioned previously, the data rate that can be achieved is dependent on the length of the bus, since the bit time interval is adjusted upwards to compensate for any increase in the time required for signals to propagate along the bus, which is proportional to the length of the bus. Bus length and bit rate are thus inversely proportional.

Error detection and management

Nodes that transmit messages on a CAN network will monitor the bus level to detect transmission errors, which will be globally effective. In addition, nodes receiving messages will monitor them to ensure that they have the correct format throughout, as well as recalculating the CRC to detect any transmission errors that have not previously been detected (i.e. locally effective errors). The CAN protocol also has a mechanism for detecting and shutting down defective network nodes, ensuring that they cannot continually disrupt message transmission.

When errors are detected, either by the transmitting node or a receiving node, the node that detects the error signals an error condition to all other nodes on the network by transmitting an error message frame containing a series of six consecutive bits of the dominant polarity. This triggers an error, because the bit-stuffing used by the signalling scheme means that messages should never have more than five consecutive bits with the same polarity (when bit-stuffing is employed, the transmitter inserts a bit of opposite polarity after five consecutive bits of the same polarity. The additional bits are subsequently removed by the receiver, a process known as de-stuffing). All network nodes will detect the error message and discard the offending message (or parts thereof, if the whole message has not yet been received). If the transmitting node generates or receives an error message, it will immediately thereafter attempt to retransmit the message.