Controller Area Network (CAN)

From AutomationWiki
Jump to: navigation, search

CAN or Controller Area Network is a serial communications bus specifically designed for in-vehicle networks but also used in industrial automation and medical equipments. CAN supports distributed real time control with high level of security. CAN was developed by Robert Bosch GmbH, in 1983 and officially released in 1986 at the Society of Automotive Engineers (SAE) congress, which is considered the ‘Birth of CAN’. Intel (82526) and Philips (82C200) are the first CAN controller chips. In the early 1990s, Bosh submitted CAN for standardization and consequently first ISO standard for CAN ISO-11898 was published in 1993.

Mercedes was the first automotive manufacturer to deploy CAN and soon BMW, Audi and VW followed suit. Since then, the complexity of automotive electronics has grown manifold. In the 1990s, Mercedes, BMW, Audi and VW cars had 5 or less networked electronic control units (ECUs), which increased to around 40 before the new millennium dawned. This demanded cost-effective networking solutions that would replace cumbersome point-to-point wiring and maintain hundreds of separate connection.

CAN provides high speed networks (500 kbits/s) connecting chassis and power-train ECUs, as well as low speed networks (100 or 125 kbits/s). The following diagram shows the network architecture of VW Passat, which explains how a number of CAN buses are used to connect around 45 ECUs in that vehicle. There are 3 Local Interconnect Networks (LIN), complementary technology to CAN, in the diagram. LIN provides inexpensive, low speed (20 Kbits/s) connectivity.


According to the Bosch manual, CAN has the following properties:

  • prioritization of messages
  • guarantee of latency times
  • configuration flexibility
  • multicast reception with time synchronization
  • system wide data consistency
  • multimaster
  • error detection and signalling
  • automatic retransmission of corrupted messages as soon as the bus is idle again
  • distinction between temporary errors and permanent failures of nodes and
  • autonomous switching off of defect nodes

CAN protocol is subdivided into different layers. The primary division is:

  • CAN object layer
  • CAN transfer layer
  • Physical layer

The first two layers provide the functionalities of the ISO/OSI data link layer. The object layer is mainly concerned with message filtering. The main functionalities are:

  • Finding which messages are to be transmitted
  • Deciding which messages received from the transfer layer are to be used
  • Providing an interface with the application layer hardware

The object layer provides much freedom in defining the object handling.

The transfer layer is the actual kernel of the protocol. It decides whether the bus is free to start transmitting or receiving a new message. It also provides some bit timing. However, there is no scope for modification in this layer.

The transfer layer functionalities are:

  • Controlling the framing
  • Performing the arbitration
  • Error checking
  • Error signaling
  • Fault confinement

The physical layer actually transfers the bits between different nodes. There is much freedom in choosing the physical layer, but within one network, all nodes should have the same physical properties.

The following table depicts the CAN layers:

Application Layer

Object Layer

  • Message
  • Filtering Message and Status Handling

Transfer Layer

  • Fault Confinement
  • Error Detection and Signalling
  • Message Validation
  • Acknowledgment
  • Arbitration
  • Message Framing
  • Transfer Rate and Timing

Physical Layer

  • Signal Level and Bit Representation
  • Transmission Medium

The CAN protocol uses the following frame types for message transfer:

  • Data frame
  • Remote frame
  • Error frame
  • Overload frame

The data frame carries data from the transmitter to receiver. The data frame consists of seven different bit fields. There are two formats for data frames.

  • Base frame with 11 identifier field
  • Extended frame with 29 identifier field

The following diagram explains the construction of a data frame.

Sometimes a receiving node can initiate data transmission by sending a remote frame to the source. A remote frame to consists of six different fields.

The Arbitration Field of a data/remote frame consists of the IDENTIFIER and the RTR bit. This RTR bit is the remote transfer request bit. In case of a data frame the RTR is 0 i.e., dominant and in case of a remote frame it is 1 i.e., recessive.

Error frame consists of two different fields. The first field is given by superposition of error flags contributed by different stations and the second is the error delimiter. There are two types of error flags. When a node detects a ‘error active’ in the network, it transmits and ‘Active Error Flag’ and if a node detects an error in ‘error passive’ state, the node transmits the ‘Passive Error Flag’.

An Overload frame is transmitted to inject a delay between data and/or remote frames. There are two situations when a overload frame is transmitted:

  • The receiver needs a delay of the next data/remote frame
  • A ‘dominant bit has been detected during intermission

The overload frame consists of two bit fields – the overload flag and the overload delimiter.

The data frames and remote frames are separated from all preceding frames (data frame, remote frame, error frame or overload frame) by a bit field, which is called the ‘Interframe Space’. This interframe space contains the bit fields – Intermission and bus idle; and for the transmitting ‘error passive’ stations a Suspended Transmission Field.

CAN frames are coded by bit-stuffing method. Whenever, a transmitter detects five consecutive identical bits it inserts a complementary bit in the actual transmitted bit stream. The frame segments – Start of frame, Arbitration field, Control field, Data field and CRC sequence are coded by bit stuffing, the remaining bit fields are fixed.