We use cookies on our website to provide you with the best possible service and to further improve our website. By clicking the "Accept All" button, you agree to the use of all cookies. You can limit the cookies used by clicking on "Accept selection". Further information and an option to revoke your selection can be found in our privacy policy.

Necessary:

These cookies are necessary for basic functionality. This allows you to register on our website and forum or order products with our online shop.

Statistics:

With these cookies, we collect anonymized usage data for our website. For example, we can see which content is interesting for our visitors and which resolutions are used. We use the information to optimize our website to provide you with the best possible user experience.

Necessary
Statistics

show more

CAN – A Short Introduction

The "History" of CAN

The availability of low-cost, high-performance microelectronic components allowed the automotive industry to introduce autonomous electronic control units (ECUs) for different functional areas, such as ignition, transmission control, and antilock braking systems. It quickly became apparent that, for further functional improvements – and thus a significant enhancement in driving behavior – the synchronization of all processes distributed across the various control devices was necessary, achieved through controlled data exchange between the devices.

The introduction of digital communication systems in the automotive industry was also driven by the growing number of body and convenience electronics that needed to be connected, such as climate control, seat and mirror adjustment, electric windows, anti-theft systems, and central lighting and locking mechanisms. In the automotive field, a digital communication system should primarily reduce the amount and length of wiring and mitigate critical cabling points, such as the grommet from the car interior to the front doors.

Due to the particularly high demands on the robustness of data transmission  in an environment full of electromagnetic interference, it was necessary to develop a suitable communication concept. This marked the starting point for the development of the Controller Area Network (CAN) protocol, initiated by Bosch in 1983. In the meantime – in addition to the use in cars – CAN is present in a wide range of application areas:

 

  • Utility vehicles (garbage and firefighting trucks)
  • Public transport (railways, trains, tramways, buses)
  • Agriculture & forestry (tractors, etc.)
  • Military
  • Aviation and Maritime
  • Buildings (elevators)
  • Construction (cranes, excavators, etc.)

 

Bus Topology, Number of Participants

CAN networks are typically arranged in line structures with terminating resistors of 120 Ohms at each end of the line (see fig.). Stubs are permitted to a limited extent, and a star-type bus is also possible (e.g. in automotive applications). The number of participants (nodes) in each network is not limited by the protocol but depends on the performance of the components used.

CAN repeaters have multiple uses when CAN networks need to be extended:
They can be used to establish a physical coupling of two or more segments of a CAN bus system, to implement tree or star topologies, or to add long drop lines. In addition, network segments can be electrically decoupled using a galvanically isolated repeater.

 


Figure 1: Line topology of a CAN network

 

CAN Messages 

Communication on the CAN bus is carried out via “messages” which contain both control bits and data bits. The structure of such a message is called a frame.
 

  • Data Frame: Used for transmitting data from a transmitter to one or more receivers at the initiative of the data source (transmitter).
  • Remote Frame: Allows a bus participant (receiver) to request the transmission of a specific message from a data source.
  • Error Frame: Signals to all bus participants  (transmitters or receivers) that an error in transmission has been detected.
  • Overload Frame: Used by a CAN controller to indicate overload. This frame is no longer implemented today, as the performance of modern controllers is sufficient.

 

Message Exchange According to the Producer-Consumer Principle

In contrast to a node-oriented transmission, in which a message is exchanged between two specific nodes, the transmission of CAN messages is based on the Producer-Consumer Principle. A message transmitted by a node (producer) can be read by all other nodes (consumers). To this end, messages are not marked with a destination but with a unique message identifier. Sending messages to all nodes of a network is also called broadcasting.

 


Figure 2: 11-bit identifier (standard format, CAN specification 2.0A)

  • SOF: Start of Frame = one dominant bit
  • RTR: Remote Transmission Request – if RTR-Bit is set it defines a Remote-Frame
  • IDE: Identifier Extension, 1 bit
  • r0: reserved bit
  • DLC: Data Length Code = 4 bits (number of bytes in data field, 0 to 8 bytes, values 9 to 15 are not supported)

 

The (message) identifier denotes the content of the CAN message, not the device. In a measurement system, for example, a separate identifier may be assigned to the parameters temperature, voltage, and pressure. However, several parameters can also be combined under a single identifier if the total data does not exceed the maximum length of the data field.
The receiving devices decide on the basis of the identifier whether a message is relevant to them and filter the relevant messages from the data stream available on the bus.


The standard format of a CAN identifier is usually 11-bit, allowing 2,048 different messages per system. This number is sufficient for most applications. However, using 29-bit identifiers (Extended Format) makes it possible to define much more different messages. Usually the 29 bits are structured and used for special applications (e.g., trucks, SAE J1939).

 

Message Format

The beginning of a message (see image) is signaled by a leading dominant bit, followed by the 11-bit message identifier and an additional bit that distinguishes between a data message and a remote transmission request (RTR) message. A network node may request the transmission of a particular message from another node in the system. However, the remote node must be programmed to respond to such an RTR message.
The control field specifies the transmission format (standard/extended) of a message and the number of subsequent data bytes.


The data field of a CAN message may contain zero to eight data bytes. The data field is followed by the 15-bit CRC segment, which allows the receiver to verify the received message. In the acknowledge field, the transmitter of a message expects confirmation of error-free reception from at least one receiving network node. This confirmation – used exclusively for fault isolation on the transmitter side – is provided by all error-free receiving nodes on the network by sending a dominant bit in the acknowledge slot.
The end-of-frame field (EOF) denotes the completion of an error-free transmission of a CAN message.

 


Figure 3: Format of a standard CAN message (Data Frame)

  • Start of Frame (SOF) = one dominant Bit
  • Arbitration field, consisting of an identifier segment (11 bits or 29 + 2 bits) plus an RTR bit (Remote Transmission Request)
  • Control field (CTRL) = 6 bits
    - Identifier Extension (IDE) = 1 bit
    - reserved = 1 bit
    - Data Length Code (DLC) = 4 bits (number of bytes in data field, 0 to 8 Bytes, values 9 to 15 are not supported)
  • Data field  (DATA) = 0 to 8 x 8 bits
  • Checksum (CRC) = 15 bits followed by a recessive CRC delimiter bit
  • Acknowledgment field (ACK) = 2-bit length, consisting of an ACK bit plus a recessive ACK delimiter
  • End of Frame (EOF) = 7 bits (recessive)
  • Intermission (IFS – Intermission Frame Space) = 3 bits; min. number of recessive bits separating consecutive messages

     

Multimaster-Capable, Event-Oriented Message Transmission

Each node of a CAN network can start sending a message as soon as the bus is free. It may happen that more than one network node begins transmitting a message at the same time. Thus, a selection process (bus arbitration) is required to ensure that only one node continues with the transmission of its message.

Because each node can initiate a message transfer, direct information exchange between all participants in the network is possible. The result is a much lower bus load and a reduced requirement for data transmission rate compared to cyclic message transmission.

 

Lossless, Bitwise Arbitration

Arbitration guarantees smooth and proper message transfer on the CAN bus. During the arbitration phase, it is determined which of the simultaneously transmitted messages has the highest priority. Only the network node sending this message may proceed with the transmission after arbitration. The message with the lowest value of the message identifier has the highest priority.
During the arbitration phase which includes the transmission of the message identifier and the RTR bit, each node monitors the signal level on the bus.

If a network node, itself sending a recessive level (a logic 1), detects a dominant bus level (a logic 0), it immediately interrupts its transmission process and switches to the receiving state. As with every bus arbitration, once a message is sent, the procedure ensures lossless bus access.

 


Figure4: Principle of lossless, bit-wise bus arbitration

Nodes 1, 2,  and 3 start an arbitration process at the very same time. At point 2, node 2 detects that the bus doesn't have the recessive level it intended to transmit and cancels its arbitration process, thus the transmission of remaining frame. At point 3, node 1 resigns. At point 4 (end of the arbitration process), node 3 transmits its data.

 

Priority-Oriented Communication

The arbitration process described above guarantees that the message with the highest priority is transmitted as soon as the bus is free. The principle of priority-oriented communication enables very efficient utilization of the bandwidth available for data transmission. It ensures that low-priority messages can use the bus without significantly delaying the transmission of high-priority messages. For the highest-priority message at a transfer rate of 1 Mbit/s, the resulting maximum latency is 130 bit times. On the other hand, when designing a CAN system, care must be taken to ensure that high-priority messages do not permanently occupy the bus. This can be achieved by introducing so-called transmission blocking times (CANopen: Inhibit Time).

 

Bitrate and Bus Length

The principle of bitwise arbitration used in CAN requires a comparison of the local bit levels of all nodes distributed across the bus network within a single bit time interval.

Since the signal propagation time – required for the dispersion (propagation) of the signal over the bus – is proportional to the length of the bus, the duration of a bit interval must increase with bus length. The maximum possible network size is therefore essentially determined by the signal propagation time of the bus medium: at 1 Mbit/s, for example, a network span of up to 40 m is possible, while at 80 kbit/s, the network size may exceed 1000 m.

 


Figure 5: Ratio of data rate to cable length
The dashed line shows the rule of thumb for data rates < 400 kbit/s and for line lengths > 100 m. The gray area shows the permitted use without consideration of electrical transit times or other restrictive parameters.
 

Maximum bus length (bus expansion) and maximum bit rate thus behave inversely. For a bus length of more than 100 m the following rule of thumb can be used: Bit rate (in Mbit/s) x bus length (in m) ≤ 60

 

Error Detection and Fault Isolation

One of the main features of the CAN protocol is its strong ability to detect transmission errors. This allows CAN to meet the very high standards required for networking control devices within vehicles.

The high capability for error detection is achieved through a combination of several measures. One of the most effective is the monitoring of the bus level by the sender of a message (bit monitoring). In this way, all globally effective errors are detected. In addition, each message receiver also checks every received message using the CRC segment as well as fixed format elements. This makes it possible to detect even locally effective errors.

In addition to detecting transmission errors, the CAN protocol also includes a mechanism for identifying and disconnecting defective nodes. This ensures that faulty network nodes do not continuously interfere with message transfer.

 

Error Signaling

Unlike communication concepts with subscriber-oriented transmission, CAN – as a message-oriented protocol – follows the principle of error signaling, where each node checks every message transmitted on the bus for accuracy.

Once a sending or receiving node detects an error, it signals this to all other nodes by sending an error message (Error Frame). This frame contains an (otherwise invalid) bit sequence of six bits with the same polarity, normally a dominant bit sequence. All nodes detect the error signal and discard the part of the message already received. In this way, a consistent dataset is ensured for all subscribers in the network.
Once a sending node has transmitted or received an error frame, it immediately attempts to retransmit the previous message via bus arbitration.

The error signaling mechanism ensures that message exchange remains accurate and consistent among all operational subscribers in the network. Since error signaling occurs immediately after an error is detected, very short recovery times are guaranteed. Furthermore, the fact that the bus is only additionally occupied when an error occurs offers a significant advantage over acknowledgment methods: a much lower additional bus load.

 

Higher-Layer Protocols

The CAN protocol described above, standardized in ISO 11898, corresponds to a Layer 1/2 protocol in the OSI model of data communication. However, further functions are required to realize complete networks.

Two standards are widely used in embedded systems and industrial automation: CANopen and DeviceNet. CANopen is the dominant standard for embedded network applications, while DeviceNet is mainly used in industrial automation, particularly in systems from Rockwell Automation. In the field of commercial vehicles, the SAE J1939 standard is also applied.