How CAN works

Tomorrow's Technology Today

How CAN works

Data messages transmitted from any node on a CAN bus do not contain addresses of either the transmitting node, or of any intended receiving node. Instead, the content of the message (e.g. Revolutions Per Minute, Hopper Full, X-ray Dosage, etc.) is labeled by an identifier that is unique throughout the network. All other nodes on the network receive the message and each performs an acceptance test on the identifier to determine if the message, and thus its content, is relevant to that particular node.

If the message is relevant, it will be processed; otherwise it is ignored. The unique identifier also determines the priority of the message. The lower the numerical value of the identifier, the higher the priority. In situations where two or more nodes attempt to transmit at the same time, a non-destructive arbitration technique guarantees that messages are sent in order of priority and that no messages are lost.

Bit encoding

CAN uses Non Return to Zero (NRZ) encoding (with bit-stuffing) for data communication on a differential two wire bus. The use of NRZ encoding ensures compact messages with a minimum number of transitions and high resilience to external disturbance.

The physical bus

The two wire bus is usually a twisted pair (shielded or unshielded). Flat pair (telephone type) cable also performs well but generates more noise itself, and may be more susceptible to external sources of noise.

Robustness

CAN will operate in extremely harsh environments and the extensive error checking mechanisms ensure that any transmission errors are detected. See the 'Error Handling' section of this site for more details.

The ISO11898 standard "Recommends" that bus interface chips be designed so that communication can still continue (but with reduced signal to noise ratio) even if:

- Either of the two wires in the bus is broken
- Either wire is shorted to power
- Either wire is shorted to ground

Network Flexibility and Expansion

The content-oriented nature of the CAN messaging scheme delivers a high degree of flexibility for system configuration.

New nodes that are purely receivers, and which need only existing transmitted data, can be added to the network without the need to make any changes to existing hardware or software.

Measurements needed by several controllers can be transmitted via the bus, thereby removing the need for each controller to have its own individual sensor.

How Arbitration Works on the CAN Bus

In any system, some parameters will change more rapidly than others. For example - parameters that change quickly could be the RPM of a car engine, or the current floor level of an elevator (US) - lift (UK). Slower changing parameters may be the temperature of the coolant of a car engine.

It is likely that the more rapidly changing parameters need to be transmitted more frequently and, therefore, must be given a higher priority.

To determine the priority of messages, CAN uses the established method known as Carrier Sense, Multiple Access with Collision Detect (CSMA/CD) but with the enhanced capability of non-destructive bitwise arbitration to provide collision resolution, and to deliver maximum use of the available capacity of the bus.

Non-Destructive Bitwise Arbitration

The priority of a CAN message is determined by the numerical value of its identifier.

The numerical value of each message identifier (and thus the priority of the message) is assigned during the initial phase of system design.

The identifier with the lowest numerical value has the highest priority. Any potential bus conflicts are resolved by bitwise arbitration in accordance with the wired-and mechanism, by which a dominant state (logic 0) overwrites a recessive state (logic 1).

The Benefits

Non-destructive bitwise arbitration provides bus allocation on the basis of need, and delivers efficiency benefits that can not be gained from either fixed time schedule allocation (e.g. Token ring) or destructive bus allocation (e.g. Ethernet.)

With only the maximum capacity of the bus as a speed limiting factor, CAN will not collapse or lock up. Outstanding transmission requests are dealt with in their order of priority, with minimum delay, and with maximum possible utilisation of the available capacity of the bus.

CAN Message Format

Message Frames

In a CAN system, data is transmitted and received using Message Frames. Message Frames carry data from a transmitting node to one, or more, receiving nodes.

The Standard CAN protocol (version 2.0A), also now known as Base Frame Format, supports messages with 11 bit identifiers.

The Extended CAN protocol (version 2.0B), also now known as Extended Frame Format, supports both 11 bit and 29 bit identifiers.

Most 2.0A controllers transmit and receive only Standard format messages, although some (known as 2.0B passive) will receive Extended format messages - but then ignore them. 2.0B controllers can send and receive messages in both formats.

2.0A Format

A Standard CAN (Version 2.0A) Message Frame consists of seven different bit fields:

A Start of Frame (SOF) field - which indicates the beginning of a message frame.

An Arbitration field, containing a message identifier and the Remote Transmission Request (RTR) bit. The RTR bit is used to discriminate between a transmitted Data Frame and a request for data from a remote node.

Fig 3.CAN 2.0A Message Frame

A Control Field containing six bits:
* two reserved bits (r0 and r1) and
* a four bit Data Length Code (DLC). The DLC indicates the number of bytes in the Data Field that follows

A Data Field, containing from zero to eight bytes.

The CRC field, containing a fifteen bit cyclic redundancy check code and a recessive delimiter bit

The ACKnowledge field, consisting of two bits. The first is the Slot bit which is transmitted as recessive, but is subsequently over written by dominant bits transmitted from any node that successfully receives the transmitted message. The second bit is a recessive delimiter bit

The End of Frame field, consisting of seven recessive bits.

Following the End Of Frame is the INTermission field consisting of three recessive bits.

After the three bit INTermission period the bus is recognised to be free. Bus Idle time maybe of any arbitrary length including zero.

2.0B Format

The CAN 2.0B format provides a twenty nine (29) bit identifier as opposed to the 11 bit identifier in 2.0A.

Version 2.0B evolved to provide compatibility with other serial communications protocols used in automotive applications in the USA. To cater for this, and still provide compatibility with the 2.0A format, the Message Frame in Version 2.0B has an extended format.

The differences are:

- In Version 2.0B the Arbitration field contains two identifier bit fields. The first (the base ID) is eleven (11) bits long for compatibility with Version 2.0A. The second field (the ID extension) is eighteen (18) bits long, to give a total length of twenty nine (29) bits.

- The distinction between the two formats is made using an Identifier Extension (IDE) bit.

- A Substitute Remote Request (SRR) bit is also included in the Arbitration Field. The SRR bit is always transmitted as a recessive bit to ensure that, in the case of arbitration between a Standard Data Frame and an Extended Data Frame, the Standard Data Frame will always have priority if both messages have the same base (11 bit) identifier.

All other fields in a 2.0B Message Frame are identical to those in the Standard format.

2.0A and 2.0B Compatibility

2.0B controllers are completely backward compatible with 2.0A controllers and can transmit and receive messages in either format.

Note, however, that there are two types of 2.0A controllers:

- The first is capable of transmitting and receiving only messages in 2.0A format. With this type of controller, reception of any 2.0B message will flag an error.

- The second (known as 2.0B passive) is capable of sending and receiving 2.0A messages. They will also acknowledge receipt of 2.0B messages - but then ignore them.

Therefore, within the above mentioned constraints it is possible to use both Version 2.0A (with 2.0B passive capabilities) and 2.0B controllers on a single network.

The number of unique identifiers available to users, on a single 2.0A network, is 2,032 (2 to the power 11 - 2 to the power 4).

Leaving aside the use for compatibility purposes with American buses, the number of unique identifiers available on a 2.0B network is in excess of 500 million!