Notes on CANbus

Author: Jon Bell

Date: 20/9/01

Ref: SD/BCG/PR/CAN/01

1.Introduction

The aim of these motes is to provide an introduction to CANbus and a guide to sources of further information on the protocol. While an attempt will be made to keep to a fairly tidy structure, the idea is that these notes will be added to as I learn more about CANbus, so the structure may deteriorate rather.

In general I shall refer to the source of information briefly in the text, providing a detailed reference (url, for example) in a sort of bibliography at the end. Many web sources on CANbus provide introductions which are fairly similar to each other, so many of the references are pretty much interchangeable.

I have tried to write these notes in the light of what is likely to be of interest the project, so I have not gone into great detail about the message format for example.

2.CANbus introduction

Controller Area Network (CAN) is a network protocol developed by Bosch for vehicle systems, but which is coming into use for linking distributed controllers, sensors etc in other fields. Bosch have published a specification [1]. Any reference herein to “the spec” means this specification, not the ISO 11898 one, which I have not seen (it costs!).

CAN is a CSMA/CD protocol (some sources have CSMA/CR for similar protocols) that uses non-return to zero coding with bit stuffing. It supports speeds of up to 1Mb/s so is an SAE class C protocol, suitable for real time control applications.

Messages are not addressed to intended recipients, but the sender’s identifier is included, and this tells the receivers what data it contains so the receiver ignores it if it is not interested. Messages are given a priority according to the sender’s address, so the priority of messages is decided at the design stage.

In the spec [1] there are two standards for CAN 2.0, imaginatively called A and B. These differ in message format (see section 4), B has an extended message format, with a 29 bit identifier, as opposed to A’s 11 bit one.

In basic can (not to be confused with standard CAN) each controller on the network is interrupted by every message on the bus. In full CAN, the CAN devices add filtration of the messages, so a controller is only interrupted by those messages the filter passes, that is those of interest to that controller.

The notes on CANbus in Automobile Electrical and Electronic Systems [5] draw attention to the difference between having a local intelligent control module (for example, for all functions located in the driver’s door) and having the intelligence actually in the actuators, so control is distributed, and each actuator (and each sensor) is on the bus itself.

3.Network access, collision detection and resolution

Binary zero is represented by a “dominant” state in the bus and binary one by a recessive state, so a binary zero takes precedence over a one, so lower numbered identifiers have priority over higher numbered ones.

CAN is a CSMA/CD protocol. If the network is idle, any node can send a message. If two messages are sent simultaneously, the node that sends a recessive bit, but detects a dominant bit stops transmitting, leaving the network free for the higher priority message. The higher priority message is not corrupted (Non-destructive bitwise arbitration). As this strategy resolves collisions and does not merely detect them, some sources describe protocols with a similar collision strategy as CSMA/CR, Carrier Sense Multiple Access/Collision Resolution. The identifier and RTR fields (see section 4) are used for collision arbitration. Therefore arbitration breaks down if two nodes can send data (as opposed to remote request) messages with the same identifier, as the clash will not be identified until later in the message, giving rise to a bit error. Each node must send data messages with a unique identifier. This has the side effect that if, say, all four road wheels had rotation sensors (for ABS and traction control) they would each need their own identifier, so they would have an order of priority. It seems to me not unreasonable to suggest that this could lead to conflicts in designing the system, which I do not propose to discuss here as it is outside the scope of the project.

This is supposed to guarantee latency, but surely can only do so for messages of high priority? Clearly this guarantees the highest priority message access to the network once the current message transmission is complete. The second highest priority message is guaranteed access after that, provided the top priority message source doesn’t broadcast continuously, so this is pretty much guaranteed. Surely, however, as one moves down the order of priority, eventually one is going to reach a point where a high priority source might be ready to transmit again while a low priority source is still waiting, so its latency is not guaranteed. This is perhaps one reason why the SAE J2284-500 standard is limited to so few nodes? LOOK HARDER. How well this works will inevitably depend on loading of the bus(?) - how heavily used does it get, typically? LOOK HARDER! It seems reasonable to suppose that rotation sensors (for wheel rotation, engine revs etc) cannot send data continually, as it takes time to find the speed, so in practice this might limit bus load sufficiently for latency to be OK. There is a paper on Guaranteeing Message Latencies on CAN [11]. I have not yet found a copy.

4.Message format

The format of the message frames is to be found in detail in the Bosch spec [1] or in less detail in the omegas.co.uk stuff [2] and the Kvaser website [3]. The standard CAN (2.0A) frame has an 11 bit identifier, while an extended CAN (2.0B) frame has a 29 bit identifier, for compatibility with other protocols used in the US vehicle industry.

The standard identifier format allows for 2032 nodes on the network (2 to 11 =- 2 to 7) and the extended identifier allows more, but as the extra 18 identifier bits are needed for compatibility with other protocols, their use is restricted. The SAE J2284-500 standard [4] allows for any number of nodes between 2 and 16, inclusive, which doesn’t seem many.

A 2.0A compliant device will flag an error if presented with a 2.0B message, unless it is “2.0B passive”, when it will tolerate, but ignore, messages in 2.0B format. 2.0B devices are backward compatible, and can transmit and receive messages in either format. The RTR field (set to 1 if the message is a request for information) follows the identifier. As such a “remote request” frame uses the identifier of the source of the required data, this means that data takes precedence over a request for that data, but a request for high priority data takes precedence over lower priority data. These remote request frames are apparently rarely used. The identifier field and RTR field are used in collision resolution.

The data field can contain from zero to eight bytes, its length being stated by a 4 bit DLC field that immediately precedes the data field.

The data field is followed by a 15 bit cyclic redundancy check, a delimiter, acknowledgement field and end of frame and intermission fields. After these and a set idle time (which may be zero) another node can start transmission.

5.Error detection

There are 5 error detection mechanisms: -

  1. Cyclic redundancy check. Each message contains a 15 bit CRC code computed by sender and checked by receivers, who will flag any errors. More in the spec (in black binder)
  2. Frame check. At certain points in the frame, the correct value is predefined.
  3. ACK(nowledgement) Error Check. If transmitter determines an error has not been acknowledged, an ACK error is flagged.
  4. Bit Monitoring. A transmitter checks the network and flags a bit error if the value on the bus is not that sent. This does not happen during transmission of the identifier field, of course, as that is how a collision is detected.
  5. Bit stuffing After 5 consecutive bits of the same value, a bit of the opposite value is added to the frame.

If an error is detected, an error frame is sent, aborting the transmission.

Error confinement (unique to CAN?) provides a mechanism for distinguishing between temporary and permanent errors. Each node has two error counters (for transmit and receive) which are incremented when errors are found. It is covered in more detail in the spec [1], but briefly each receive error increments its counter by one, and each transmit error increments its counter by 8. If either counter goes above 127 the node concerned goes into “error passive” mode. In this mode it can still transmit and receive messages, but is restricted in flagging errors. If a device’s transmit error counter goes above 255, the device will go into “bus off” mode and will cease to be active. This condition will clearly need to be modelled in simulating CANbus systems for FMEA. This seems to imply that we must allow for the modelling of repeat errors or for modelling the network as though the counter(s) had reached a level such that devices were going into “bus off” mode.

Error detection is thorough. Omegas stuff [2] suggests that the undetected error probability is 10 to the power of –11. Of course, detected errors will result in loss or delay to messages, which effects might well need modelling.

6.Bit timing and synchronisation

This is covered in the spec [1], of course, and there is an introduction to this in the Omegas material [2]. Briefly, a bit time consists of four non-overlapping segments, Sync-seg, Prop-seg, Phase-seg1 and Phase-seg2. An edge should lie within Sync-seg, while Prop-seg is used to compensate for delay times in the network. It is therefore the sum of twice the signal propagation time on the bus, the input comparator delay and the output driver delay, so is characteristic to the network. Phase-seg1 and Phase-seg2 are used to compensate for edge phase errors. They can be lengthened or shortened by resynchronisation. The sampling point is the boundary between Phase-seg1 and Phase-seg2. As non-return to zero encoding is used, there need not be an edge during Sync-seg, but bit stuffing ensures that there will be an edge after five edge-free ones.

There is a paper on The Configuration of the CAN bit timing [6] which describes the bit synchronisation algorithm and parameters to be considered in calculating the CAN bit time.

7.CAN in the ISO/OSI stack and higher level protocols

The scope of the CANbus protocol covers the physical and data link layers of the ISO/OSI model. The spec [1] refers to three levels in the CANbus protocol; physical layer, transfer layer and object layer. The physical layer is not defined in the Bosch spec, but is typically shielded or unshielded twisted pair. Idle state is both lines at +2.5 volts. A dominant bit reduces one line, known as CAN_L, to zero, while increasing the other line (CAN_H) to +5 volts while a recessive bit is close to the idle value, with CAN_L slightly above CAN_H, so is “over written” by a dominant bit. A standard for the physical layer of a 500 KBPS vehicle network is defined in SAE J2284-500 [4].

The transfer and object layers between them comprise all the services and functions of the ISO/OSI data link layer. These are discussed in the spec.

Various higher level protocols might be added to CAN itself. Kvaser [3] has some material on this, and Omegas [2] have some links on their website. Of these the Kvaser source is perhaps the more useful. I have also seen an article on higher level protocols [7] that gives an overview of the most important higher layer protocols, especially those used in industrial automation.

The Can in Automation (CiA) trade organisation [8] supports various higher level protocols

  • CANopen
  • DeviceNet
  • CAL (CAN application layer)
  • CAN Kingdom
  • SDS (Smart Distributed System)

CiA is an organisation mainly interested in using CAN for industrial automation so it may well be that the protocols listed above are more common in that field than in the automotive field.

In addition to these, Kvaser list J1939 and OSEK. There is an introduction to OSEK in the companion notes, Miscellaneous Notes [9]. J1939 is an SAE standard for a Truck and Bus Control and Communications Network, that uses the CAN protocol, but includes documentation (though not explicit definitions) for each layer in the ISO/OSI stack. There is a brief introduction to J1939 in the companion Other automotive industryprotocols [10]. In addition to those listed on the Kvaser site, there is FNOS that appears to be a Ford alternative to OSEK. There is a piece on this in [9].

8.References

[1] Robert Bosch GmbH, CAN Specification version 2.0, pub by Bosch. 1991. I have a copy in the office or in the SoftFMEA document repository. The Bosch CANbus website is at

[2] Omegas’ website is at I have paper copies of some of their material. On trying this url when checking the references, it failed.

[3] Kvaser are a Swedish company dealing with CAN based systems. Their website is at

[4] Society of Automotive Engineers, High speed CAN for vehicle applications at 500 Kbps, SAE J2284-500. There is a copy in the SoftFMEA document repository. The SAE website is at

[5] Unknown, Automobile electrical and electronic systems I only know of this book because Neal had a copy in his office, he photocopied the chapter that includes noted on CANbus. Ask Neal!

[6] Hartich, F and Bassemir, A (Robert Bosch GmbH), The Configuration of the CAN Bit Timing, presented at the 6th international CAN Conference. It can be had in pdf from Bosch ( or from the SoftFMEA document repository.

[7] Prof. Dr.-Ing. K Etschberger, CAN-based Higher Layer Protocols and Profiles from

[8] Can in Automation has a website at

[9] Bell, Jon Miscellaneous Notes in the SoftFMEA document repository at /dcs/autosteve/SoftFMEA/documents/background/protocols/general/misc_notes

[10] Bell, Jon Other automotive industry protocols in the SoftFMEA document repository at /dcs/autosteve/SoftFMEA/documents/background/protocols/general/other_protocols

[11] Tindell, Dr K and Burns, A, Guaranteeing Message Latencies on CAN, in proc 1st International CAN Conference, CiA Erlangen 1994.

9.CANbus sources

Bibliographic references to sources that look interesting.

Farsi M, Ratcliff K and Barbosa M

An overview of controller area network

Computing and Control Engineering Journal, 1999, Vol 10 Iss. 3 pp113-120.

Thompson H A, Benitez-Perez H, Lee D, Ramos-Hernandez D N and Fleming P J (Sheffield University) and Legge C G (Rolls-Royce Plc.)

A CANbus-based safety-critical distributed aeroengine control systems architecture demonstrator

Microprocessors and Microsystems, (UK), 29 Nov 1999, Vol 23 No 6 page: 345

Navet N and Song Y-Q (LORIA-INPL ENSEM 2, France) and Somonet F (Institut E. Cartan ESSTIN, France)

Worst-case deadline failure probability in real-time applications distributed over controller area network

Journal of Systems Architecture, (Netherlands), 15 Apr 2000, Vol 46 No 7 page: 607

Zuberi K M (Microsoft Corp., USA) and Shin K G (Michigan University, USA)

Design and implementation of efficient message scheduling for controller area network

IEEE Transactions on Computers, (USA), Feb 2000, Vol 49 No 2 page: 182

Sparks J A (Rolls-Royce Military Aero Engines Ltd.)

Low cost technologies for aerospace applications.

Microprocessors and Microsystems, (UK), Apr 1997, Vol 20 No 8 page: 449

Cena G and Valenzano A (Politecnico di Torino, Italy)

Delay analysis of priority promotion systems

Computer Communications, (Netherlands), 15 Jul 2000, Vol 23 No 13 page: 1252

These sites have similar material to that at Omegas [2] and Kvaser [3]. They may be found easier to read (especially if the Omegas site is really dead!): -

  • seems good, but the diagrams reproduce poorly in HTML.
  • is cursed with annoying graphics, and didn’t print well (edges bled off the paper).